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1.0 INTRODUCTION 

1.1 Background 

ATM systems throughout the world are entering a period of major transition 
and change. The combination of important technological developments and 
of the globalization of the air transportation industry has necessitated a re- 
examination of some of the fundamental premises of existing ATM 
concepts. New ATM concepts have to be examined, concepts that may place 
more emphasis on: strategic traffic management; planning and control; 
partial decentralization of decision-making; and added reliance on the aircraft 
to carry out strategic ATM plans, with ground controllers confined primarily 
to a monitoring and supervisory role. 'Free Flight’ is a case in point. 

In order to study, evaluate and validate such new concepts, the ATM 
community will have to rely heavily on models and computer-based 
tools/utilities, covering a wide range of issues and metrics related to safety, 
capacity and efficiency. The state of the art in such modeling support is 
adequate in some respects, but clearly deficient in others. It is the objective 
of this study to assist in: (i) assessing the strengths and weaknesses of 
existing fast-time models and tools for the study of ATM systems and 
concepts and (ii) identifying and prioritizing the requirements for the 
development of additional modeling capabilities in the near future. 

A three-stage process has been followed to this purpose: 

1 . Through the analysis of two case studies involving future ATM system 
scenarios, as w'ell as through expert assessment, modeling capabilities and 
supporting tools needed for testing and validating future ATM systems and 
concepts were identified and described. 

2. Existing fast-time ATM models and support tools were reviewed and 
assessed with regard to the degree to which they offer the capabilities 
identified under Step 1. 

3 . The findings of 1 and 2 were combined to draw conclusions about (i) the 
best capabilities currently existing, (ii) the types of concept testing and 
validation that can be carried out reliably with such existing capabilities and 
(iii) the currently unavailable modeling capabilities that should receive high 
priority for near-term research and development. 

It should be emphasized that the study is concerned only with the class of 
"fast time" analytical and simulation models. "Real time" models, that 
typically involve humans-in-the-loop, comprise another extensive class 
which is not addressed in this report. However, the relationship between 
some of the fast-time models reviewed and a few well-known real-time 
models is identified in several parts of this report and the potential benefits 
from the combined use of these two classes of models --a very important 
subject— are discussed in Chapters 4 and 7. 
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1.2 Outline of the Study and Contents of the Report 

This section provides an outline of the contents of the study and of the 
structure of this report. To perform the three-stage process identified in 
Section 1.1, the project was subdivided into three tasks. Task 1, on the 
identification of future modeling requirements, examined two case studies 
involving future concepts, one a concept for the entire ATM system and the 
other for an ATM subsystem. These two case studies were specified in 
consultation with NASA. 

The first case study concerns requirements for modeling the Free Flight 
concept. An initial review of such requirements was carried out during the 
early stages of the study and its findings are presented in Appendix A. This 
initial review indicated that there are major aspects of Free Flight which 
cannot be addressed adequately by existing models and that extensive 
additional model development would be needed to correct this problem. For 
this reason, the Free Flight case study was re-examined later in the project 
to develop more specific recommendations about corrective measures. 
These recommendations are summarized in Chapter 7 along with the other 
findings of the study. 

The second case study examines modeling requirements for Airport Surface 
Traffic Management (ASTM) Automation, a concept for improving the 
safety and efficiency of airport surface operations currently under intensive 
investigation in both the United States and Western Europe. The findings 
of this second case study, which also identified several important challenges 
and gaps with respect to modeling ASTM Automation, are presented in 
Appendix B. 

Task 2 ("identification and review of existing models and tools/utilities") 
consisted of three parts. Part 1 identified the most important existing 
models of ATM and airport operations. To this effect, an extensive 
literature review was carried out using several bibliographic sources and 
yielding several hundred references corresponding to such keywords as 
"ATC models", "airport capacity", "trajectory optimization", etc. 

A set of formal and informal criteria were then used to select, from this long 
list, a subset of models that deserved a detailed review. The formal criteria 
required the models to be: (i) “fast time”; (ii) already implemented through a 
computer program; (iii) utilized, currently or in the past, in a study or 
studies of some aspect of ATM and/or airport operations; and (iv) available 
in the public domain, be that at no —or nominal— cost or through a vendor. 
At a more informal level, peer recommendations played an important role in 
selecting a preliminary list of models as candidates for detailed review. For 
this purpose, members of the study team visited some of the principal 
agencies or organizations engaged in ATM and airport modeling in the 
United States (FAA, MITRE CAASD, CSSI and LMI) and in Europe 
(Eurocontrol, DLR, NLR, CENA and CAA/NATS). During these meetings 
models available or being utilized at these organizations were identified and 
a number of specific models were discussed in detail with competent staff 
members. In addition, numerous contacts were made by telephone or in 
person with individuals in other organizations, aimed at identifying 
important existing models. The list of models compiled through this 
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process was finally reduced further by eliminating any models which, in the 
opinion of the study team, were clearly superseded by others. For example, 
ADSIM and RDSEM, two models that have been used extensively by the 
Federal Aviation Administration (FAA) to carry out studies of capacity and 
delay at many of the busiest airports in the United States, were not reviewed 
in detail because they were deemed to have been superseded by such models 
as SIMMOD, TAAM and the Airport Machine. Similarly, such well-known 
analytical models as Blumstein's runway capacity model, were not reviewed 
since their best features were found to have been incorporated into other, 
more recent models. 

This selection procedure eventually yielded a total of 27 models, identified 
in Table 1.1, which were studied in detail during Part 2 of Task 2. The 
summary reviews of these models appear in this report. Table 1.1 also 
allocates the 27 models into nine groups, according to the primary outputs 
of the models, the methodology used (analytical or simulation -see also 
Chapter 2) and their level of detail. 

It is almost certain that some models, which are important in the view of 
some or many in the ATM community, are not among the ones listed in 
Table 1.1. Such omissions are practically unavoidable in a field in which 
there is much ongoing activity and research and where some models are 
developed primarily for internal use, but are then considered by their 
developers as "available for use by others". Any glaring gaps can, 
however, be filled up in the future. The intent of this report is that it serve 
as a "living document" whose contents and conclusions can be updated 
periodically. The latest version of the report will be maintained in the 
address 

http://web.mit.edu/aeroastro/www/labs/AATT/aatt.html 

on the Worldwide Web. Readers who wish to suggest changes or additions 
to the report are encouraged to contact Professor Amedeo R. Odoni at +1- 
617-253-7439 or at odoni@mit.edu. We also note that many other Web 
sites exist with current information about models of ATM and airport 
operations. The principal ones identified by this study are listed in 
Appendix C at the end of this report. 

The reviews of the individual models constituted the most time-consuming 
part of the study. A summary of the findings of each review, ranging in 
length from two to seven pages, was prepared. Each summary consists of 
13 sections (see Section 1.3 below for full details) addressing various 
model characteristics, such as principal inputs, principal outputs, main 
assumptions, computational characteristics, model availability, etc. Each 
review ends with a summary evaluation that offers an overall appraisal of 
the usefulness of the model and identifies specific strong and weak features. 

The model reviews were carried out by using a combination of approaches. 
In all cases, available documentation was studied and at least one interview 
was conducted with either a developer of the model or an experienced user. 
Hands-on experience was also obtained (directly or indirectly) whenever 
possible, specifically with the following twelve models: LMI Runway 

Capacity Model, FAA Aifield Capacity Model, DELAYS, AND, SIMMOD, 
TAAM, ASCENT, RATSG, MIDAS, ACIM, INM and NOISIM. For the 
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Table 1.1: Models Reviewed 

1. Quasi-Analytical Models of Airport Capacity and Delay (FAA Airfield 
Capacity Model, LMI Runway Capacity Model, DELAYS, AND) 

2. High - Level - of - Detail Simulations of Airport Operations (HERMES, 
The Airport Machine) 

3. High - Level - of - Detail Simulations of Airport and Airspace Operations 
(TAAM, SIMMOD) 

4. Intermediate - Level - of - Detail Simulations of Airport and/or Airspace 
Operations (NASPAC and spin-offs, TMAC, FLOWSIM, ASCENT) 

5. Safety Models (TOPAZ) 

6. Conflict Resolution, Workload Measurement and Airspace Management 
(RAMS, Arc 2000 [+HIPS], BDT, NARSIM, ASIM, SDAT, RATSG) 

7. Human Factors; Man/Machine Integr'n (MIDAS, PUMA, DORATASK) 

8. Cost-Benefit and Investment Models (NARIM, ACIM) 

9. Noise Models (INM, NOISIM) 


other fifteen models listed in Table 1.1, it was not feasible to obtain such 
experience, either because the models were not transportable or because 
obtaining access to them was beyond the project's resources. However, in 
all but six cases (HERMES, FLOWSIM, TOPAZ, SDAT, DORATASK 
and NARIM) it was possible to arrange for demonstrations of the models to 
one or more members of the project team. 

The third part of Task 2 was concerned with identifying and reviewing 
some generic utilities and tools that are often important in modeling airport 
and ATM operations. Examples include: demand generators, i.e., 

programs that generate demand schedules having certain user specified 
characteristics such as a given distribution of demand by time of day; 
aircraft itinerary generators which create itineraries of aircraft during the 
course of a day that resemble the itineraries typically flown by airline fleets; 
and weather generators which provide weather inputs on a local (e.g., an 
individual airport) or regional basis (e.g., a moving weather front). The 
common characteristic of these "generic utilities and tools" is that they are 
useful in numerous contexts and, if available, would be highly applicable 
with many of the models listed in Table 1.1. 

Finally, Task 3 combined the findings of Tasks 1 and 2 to draw conclusions 
about the best capabilities currently available, as well as to prepare a set of 
recommendations for future research and development efforts on ATM 
modeling. These conclusions are presented in five parts of this report: the 
introductory sections of Chapters 2, 3, 4 and 5 dealing respectively with 
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models concerned with (a) capacity and delays, (b) conflict generation, 
detection and resolution, (c) human factors and automation and (d) 
cost/bemefit assessment; and Chapter 7 which summarizes these findings in 
more general terms. 


1.3 Format of Model Reviews 

As noted above each detailed model review in this report consists of 13 
sections. The contents of each section are explaind below. 

Item 1: Primary Model Category: This is a brief descriptor of the principal 
issue emphasized by the model (e.g., “ capacity of the runway system” or 
“conflict detection and resolution”). Appropriate modifiers can be provided 
if the model spans more than one subject areas. 

Item 2; Summary: A brief description of the model (one to three 

paragraphs). This can consist of the “abstract” provided in the model 
developer’s documentation, if adequate, or a summary prepared by the 
evaluators. This section may include an identification of some of the 
fundamental features of the model, specifically: (i) primary methodology 
(e.g., analytical model, fast-time simulation, real-time simulation, 
Al/knowledge-based model, etc.); (ii) level of detail (microscopic vs. 
macroscopic approach); (iii) principal "competing" models (identifies other 
models in the same area). 

Item 3: Input Requirements: Identifies the most important inputs 

necessary to run/use the model. Also identifies, when applicable, databases 
accompanying the model, availability of default inputs, etc. 

Item 4: Outputs: Identifies the major outputs obtainable from the model. 

Item 5: Major Assumptions: Lists the major assumptions of the model 
with remarks, when appropriate, on their reasonableness. Also notes 
aspects of real-world operations which may be omitted by the model. 

Item 6: Computational Characteristics: Indicates whether a computer 

program has been written to implement the model in question. If a computer 
program does exist, the items covered (whenever such information is 
available) include: computer language used; hardware and software 
requirements; typical running times for the model; graphics or other 
interfaces; quality of model documentation; model support by sponsoring 
organization; amount of effort needed to learn how to use the model and to 
set up inputs for computer runs. To assist in compiling this information a 
brief questionnaire was prepared to be completed by the developer of the 
model or someone very familiar with it. The questionnaire can be found in 
Table 1 .2 at the end of this section. 

Item 7: Modularity and Flexibility: An indication as to how easily the 
model can be extended to include additional considerations and extensions. 
Comments may also be made on the possibility of combining the model 
with others to provide a tool of expanded scope. 
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Item 8: Status of Model: Indicates, whenever this information is 

available, whether the model in question is being actively used at this time, 
whether further model development is in progress, etc. 

Item 9: Extent of Model Validation: Information on whether or not the 
model has been validated, and if yes, in what way. 

Item 10: Principal applications: Identifies the types of issues that the 

model is best suited to address. Also provides examples, if any, of projects 
in which the model has been used in the past 

Item 11: Model Availability: Identifies the model's supplier or vendor, if 
applicable, or model's sponsoring organization. Costs are given, if 
appropriate. Contact person(s) are identified if possible. 

Item 12: Information Base for Model Evaluation: Identifies the means 
employed to prepare the evaluation of the model (interview(s), papers 
reviewed, other documentation reviewed, hands-on experience, etc.). 
Documents describing the model should be identified in detail (title; 
author(s); organization generating the report; report number; date; other 
identification information —such as NTIS number or sponsoring 
government agency, if any). 

Item 13: Summary Evaluation: Offers the evaluator's appraisal of the 

value and usefulness of the model on an absolute basis and, if possible, by 
comparing it to other models in the same area. Specific strong and weak 
features of the model should be listed to provide guidance and assistance to 
potential users of the models or to future researchers in this area. 


Table 1.2: Computational requirements questionnaire 


1 . Does code exist? ( Y / N ) 

2. Required operating 
system(s) 

3. Hardware requirements 

1. Platform(s): 

2. Memory (RAM and hard drive) 

3. Other (tape drive, input devices, monitors) 

4. Software / compiler 
requirements: 

5. Contact / availability of 
support: 

6. Evaluations 

1 . Documentation ( Poor / Adequate / Good ) 

(list major deficiencies / 

2. Startup effort / default inputs ( Low / Moderate / 

strengths): 

High) 

3. User interface ( Poor / Adequate / Good ) 

4. Typical run time: 

Name: 

Date: 

i i 
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CAPACITY AND DELAY MODELS 


2.1 REVIEW OF CAPACITY AND DELAY MODELS 

2.1.1 Definition 

Capacity and delay are two of the principal measures of performance of air 
traffic management (ATM) systems. To obtain estimates of these measures, 
a considerable number of models have been developed over the years. 
Indeed, this is the oldest area of model development in the ATM field, with 
the first significant models dating back to the late 1950s. It is also the area 
where the most advanced modeling capabilities currently exist. There is 
still, however, much room for improvement, as this section will indicate. 

It is useful to classify capacity and delay models according to three aspects: 
level of detail, methodology, and coverage. With respect to the first, we 
classify models into macroscopic, mesoscopic and microscopic, 
corresponding respectively to a low, intermediate and high level of detail. 
While the boundaries among these three classes are not particularly sharp 
(e.g., the same model might be characterized as “low-level-of-detail” by 
some or “intermediate-level” by others) it is nonetheless very useful to 
classify models along these lines. Macroscopic models omit a great deal of 
detail, since their objective is to obtain approximate answers with emphasis 
on assessing the relative performance of a wide range of alternatives. For 
example, air traffic demand may be described in such a model by simply an 
hourly rate of arrivals at an element (airport, sector, etc.) of the ATM 
system and a simple probabilistic description of how these arrivals occur 
over time (e.g., “Poisson arrivals”). These models are used primarily for 
policy analysis, strategy development and cost-benefit evaluation. Ideally 
they should be fast, in terms of both input preparation and execution times, 
so they can be used to explore a large number of “scenarios”. 

Mesoscopic models, while more detailed than macroscopic ones, are still 
rather strategic in nature. For example, a mesoscopic model may be 
concerned with aggregate flows per unit of time through one or more 
elements of the ATM system (e.g., for flow management purposes) without 
being concerned with how these flows are handled, as long as the flows 
remain below some pre-defined “capacities”. 

Finally, microscopic models are designed to deal with more tactical issues. 
Typically, such models represent aircraft on an individual basis and move 
them through the ATM elements under study by taking into consideration 
each aircraft’s performance characteristics. Such detailed features as 
conflict resolution, airport taxiway and gate selection, pushback 
maneuvering, etc., are generally included only in microscopic models. 

With respect to methodology, we distinguish between analytical and 
simulation models. The former are abstract, necessarily simplified 
mathematical representations of airport and airspace operations. By 
manipulating these expressions (either in closed form or numerically) 
analytical models derive estimates of capacity and delays in airspace and/or 
airports. In contrast, the classical approach of simulation modeling is to 
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create objects (typically aircraft) which move through the airspace segments 
and airports of interest. By observing the flows of such objects past 
specific locations (e.g., the threshold of a runway or an en route waypoint) 
and the amount of time it takes for aircraft to move between such points, the 
simulation models compute appropriate measures of capacity and delay. 
There is a strong correlation in practice between methodology and level of 
detail: specifically, analytical models tend to be mostly macroscopic in 
nature, whereas most simulations are mesoscopic or microscopic. 

Models (whether analytical or simulations) can be further distinguished in 
terms of methodology, according to whether or not they are (a) dynamic 
and (b) stochastic. Dynamic models will accept input parameters which are 
time-dependent and will capture the fluctuations over time in the 
performance metrics of airports and/or airspace traffic. Similarly, stochastic 
models will accept input parameters which are specified probabilistically 
(i.e., are random variables) and will capture the impacts of uncertainty on 
the performance metricss of airport and/or airspace traffic. Stochastic 
simulation models are often referred to as Monte Carlo simulations. 

Finally, with respect to coverage, we classify capacity and delay models 
according to whether they encompass operations of the following elements 
of airports and airspace: (1) aprons and taxiways; (2) runways and final 
approaches; (3) terminal area airspace; and (4) en route airspace. 
Combinations of more than one of these components are, of course, 
possible so that some models may be able to examine an airport in its 
entirety, or even a national or regional system of airports, terminal areas and 
en route sectors. 

2.1.2 Principal Existing Models 

Table 2.1 lists the models reviewed in this report, classified according to 
level of detail and coverage. Models which are analytical are indicated with 
an asterisk; the remaining models are simulations. 

Existing macroscopic models concentrate on runway capacities and 
associated delays or on en route sector operations. General purpose, 
macroscopic models of taxiway/apron operations and of terminal airspace 
operations do not exist, because such models need to be location-specific. 
Of the runway/final approach models listed in Table 2.1, the top two 
estimate capacity, while DELAYS and AND estimate airport-related delays. 


The LMI Runway Capacity Model is still under development and, at this 
point, covers only single-runway airports in general form. For any given 
aircraft mix and set of separation requirements, it computes (1) the all- 
departures capacity of a runway, (2) the all-arrivals capacity, (3) the number 
of “free” departures that can be performed without reducing the all-anivals 
capacity and (4) the capacity of the runway if a departure is always inserted 
between two arrivals, so that arrivals alternate with departures on the 
runway. The capacity of the runway for any other mix of arrivals and 
departures and any other sequencing of arrivals and departures can then be 
computed approximately by utilizing the four estimates above. (For 
configurations involving the simultaneous use of more than one runway, the 
model has to be extended on an ad hoc basis for each airport.) The FAA 
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Airfield Capacity Model computes the capacity of 14 different common 
runway configurations, ranging from one to four simultaneously active 
runways. Its logic differs in several significant respects from that of the 
LMI Model. DELAYS views the runway system of an airport as a queueing 
system whose “customers” are aircraft demanding to land or take-off and 
whose capacity is equal to the arrival, departure or total capacity of the 
runway system, depending, respectively, on whether one is interested in 
delays to arrivals, to departures or to the “average operation”. The model is 
based on a fast approximation scheme for solving the differential equations 
that describe a quite general dynamic queueing system. The Approximate 
Network Delays (AND) model is a complex extension of DELAYS that 
considers a network of airports, instead of a single airport, and computes 
how delays in any part of that network would “spread”, due to disruption of 
airline schedules, to the rest of the network. The model’s intent is to help 
evaluate the system-wide implications (on a national or regional scale) of 
changes in (i) the capacity of one or more airports and/or (ii) the amount or 
geographical distribution or temporal distribution of airport demand. 


Table 2.1: Classification of Analytical and Fast-Time 

Simulation Models of Capacity and Delay 



Scope of Model 




Level of Detail 
(tvpe of study) 

Aprons and 
taxiways 

Runways and final 
approaches 

Terminal area 
airspace 

En route 
airspace 

Macroscopic 

(Policy analysis, 
cost-benefit studies) 


LMI Runway 
Capacity Model* 
FAA Airfield 
Capacity Model* 
DELAYS* 

AND* 


ASIM 

SDAT* 

DORATASK 

Mesoscopic 

(Traffic flow 
analysis, cost- 
benefit analysis) 


NASPAC 

TMAC 

FLOWSIM 

ASCENT 



Microscopic 

(Detailed analysis 
and preliminary 
design) 

TA AM 
SIMMOD 




Same 

The Airport Machine 
HERMES 

RAMS 



•indicates an analytical model 

Of the en route macroscopic models, ASIM and DORATASK are fast 
approximate simulations for computing, respectively, the expected number 
of aircraft conflicts and the expected controller workload, in a single sector 
or in a set of sectors, that would result from any given pattern of traffic 
flows along a structured set of airways. SDAT is an analytical model that, 
for some given pattern of traffic flows, would support the design of en 
route sectors with the objective of minimizing sector workload resulting 
from the routine handling of traffic, as well as the resolution of conflicts. 
Thus, the principal focus of all three of these models is on controller 
workload and on aircraft conflicts (see also the next Section). They are 
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related, however, to capacity and delay in the sense that en route sector 
capacity is largely determined by controller workload, which, in turn, is 
influenced heavily by the potential number of conflicts that a controller may 
be called on to resolve. 

The four mesoscopic models listed in Table 2.1 are all recent (the oldest, 
NASPAC, was initially developed in 1988). NASPAC was initially 
designed as a national- or regional-scale, macroscopic simulation whose 
objective, like that of AND, was to study a network of airports and compute 
how delays in any part of that network would “spread”. However, many 
details were subsequently added to NASPAC, so th at today it is primarily 
used to deal with traffic flow management (TFM) issues, rather than 
predictions of capacity and delay. The focus of the other three models 
listed, FLOWS IM, TMAC and ASCENT is also on TFM. TMAC, a model 
under continuing development at MITRE) has also been used recently in 
connection with the preliminary evaluation of some of the benefits that may 
be obtained from the Free Flight concept. Of the three models, FLOWSIM 
is the most mature, while new capabilities are currently being added to the 
other two, especially the ASCENT model of the C.S. Draper Laboratory, 
which is being expanded to cover both strategic and tactical aspects of TFM. 

An important distinction in the case of microscopic models is between 
node-link and 3-dimensional (3D) models. Node-link models discretize 
airports and airspace into a number of nodes and links. Aircraft move from 
node to node along the links and conflicts occur when more than one aircraft 
try to move to a single node. These conflicts are resolved by delaying one 
or more of the aircraft at a node. By recording the amount of delay incurred 
at each node by each aircraft, the model compiles the requisite aggregate and 
distributive delay statistics. SIMMOD and The Airport Machine are node- 
link microscopic models, as are ASIM and FLOWSIM among the 
macroscopic and mesoscopic models, respectively. 

3D models allow aircraft to fly arbitrary three-dimensional routes. (When 
simulating airport surface traffic operations, these are, of course reduced to 
2D models.) In some 3D models, aircraft follow specified flight plans 
exactly; in others, aircraft dynamics equations are used to simulate aircraft 
performance. Flight paths may thus deviate from planned flight plans. 
RAMS, TAAM and HERMES are microscopic 3D models —and so are 
TMAC and ASCENT among mesoscopic models. 

Most of the models in the microscopic category are well-known. 
SIMMOD, TAAM and The Airport Machine have been used in numerous 
airspace and/or airport studies in many parts of the world. The former is a 
model developed with support from the FAA and is available at little direct 
cost, while the latter two are proprietary and carry significant license fees. 
SIMMOD and TAAM cover both airspace and airport operations, while The 
Airport Machine is limited to airport operations only. RAMS is an airspace 
operations modeler, developed recently by Eurocontrol, which also controls 
its availability. The least-known model, HERMES, has been developed by 
CA A/NATS in the UK and its use is currently limited to simulating in detail 
operations at London’s Heathrow and Gatwick Airports. 


is 


2.1.3 Individual model assessment and model comparisons 

We now identify briefly some strengths and weaknesses of the models in 
Table 2.1 and summarize some comparisons among models with 
overlapping scope. 

Beginning with macroscopic models, we observe that their potential has 
not yet been fully attained — nor is it adequately appreciated by the user 
community. In the area of airport capacity estimation, for example, a fully 
general, macroscopic model would be extremely valuable and is within easy 
technical reach. The LMI Runway Capacity Model includes some 
outstanding features (robust probabilistic approach, adoption of an air traffic 
controller’s viewpoint) but is currently limited to a single runway and has 
certain gaps in its logic. The FAA Airfield Capacity Model, by comparison, 
covers many important multi-runway configurations, but its fundamental 
building block (i.e., the underlying single-runway capacity model) has 
some fundamental weaknesses. An excellent opportunity exists to combine 
the best features of the two models to arrive at a robust, fast and quite 
accurate analytical model to compute the capacities of all but the most 
complex runway systems. Similarly, DELAYS can provide very adequate 
support for most policy-oriented studies, typically concerned with 
approximate estimates of delay costs and relative performance of a set of 
alternatives for expanding an airport or managing demand there. The 
principal deficiency of DELAYS is its aggregate nature: it does not 

distinguish among individual aircraft or types of operations, when these 
aircraft or operations share the same runway. For example, when a runway 
is being used for a mix of arrivals and departures, DELAYS will compute 
an average delay for all operations, without considering the fact that arrivals 
often receive priority over departures. This priority assignment means that 
in practice arrivals may incur less delay and departures more than the 
average value computed by DELAYS. 

AND also represents a potentially important technical development in its 
ability to approximately model analytically an entire system of airports and 
the associated delays. As such, it could emerge in the future as a superior 
alternative to NASPAC and other system-wide simulation models, because 
of its speed, simplicity and statistical robustness. However, the model is 
not yet portable (it is available only at MIT and at MITRE) and its user 
interface is still quite primitive. A more fundamental weakness is that AND 
is exclusively concerned with airport-related delays. Thus, it is more 
applicable to an environment, such as that of the United States, where most 
delays are indeed airport-related, than to one where en route sectors are also 
heavily congested, as is the case today in much of Europe. 

As we noted above, the en route macroscopic models, ASIM, SDAT and 
DORATASK are only indirectly concerned with capacity and delay, since 
their focus is on workload measurement and estimation of the expected 
number of conflicts in en route airspace. A common characteristic of these 
models is that they are new and experience with them is, as yet, insufficient 
to make any definitive judgment on their usefulness. All three are discussed 
in somewhat more detail in Section 3. 

Mesoscopic models, as mentioned earlier, are also relatively new and can 
be said to be currently in a state of transition from “first” to “second” 
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generation. The only one among these models with which extensive 
experience already exists is NASPAC. This experience has been mixed, 
with long turnaround times, high cost and results of occasionally 
questionable validity. Recent enhancements to the model earned out in 
France, at MITRE and by the FAA may have overcome some of these 
problems. FLOWSIM may emerge as a viable and much faster alternative 
to NASPAC for studies of flow management strategies, as it utilizes 
advanced software technology. However, FLOWSIM does not model en 
route airspace and thus, like AND, is more applicable to the United States 
ATM environment than that of Europe. Experience with FLOWSIM to date 
has been limited. TMAC and ASCENT are far more complex mesoscopic 
simulation environments than NASPAC and FLOWSIM and incorporate 
now (and especially in their future plans) many additional capabilities, 
including some tactical aspects of TFM. However, both models are still in 
(quite advanced) developmental stages and are not portable at this time. 

In the area of detailed (microscopic) simulation models, there are some 
interesting comparisons to be made among the three dominant airport 
simulation models. SIMMOD can be acquired at very low cost ($250 for 
the PC version, $3,900 for the workstation version) and provides a lot of 
options and flexibility and adequate stochastic features. On the negative 
side, SIMMOD is very labor intensive, requires a truly expert user, has a 
poor user interface, provides few diagnostics and “crashes” easily, 
especially the PC version. The Airport Machine, which costs about 
$20,000 for a site license, offers less flexibility and options than SIMMOD 
and is a largely deterministic model. But it is less labor-intensive than 
SIMMOD (still, however, requiring considerable resources and training), 
provides for interactive use and offers good graphics capabilities. Finally, 
TAAM is expensive ($350,000 for a site license, $14,000 per month for 
rental) and has few stochastic features. It offers, however, advanced 
software engineering features, excellent graphics, an outstanding user 
interface and a rule-based logic that gives the user many options and 
flexibility. TAAM, like SIMMOD, is still labor-intensive and requires a 
considerable amount of user training. 

In conclusion, the prospective user of any one of these three detailed airport 
simulations is faced with several difficult trade-offs (e.g., cost vs. quality of 
user interfaces vs. model features and flexibility). None can be said to 
“dominate” the other two. Prospective users should, in any event, be aware 
that all three models require significant resources and time. As for 
HERMES, CAA/NATS has reported that its performance at Heathrow and 
Gatwick has been very satisfactory. It is not clear, however, how 
generalizable to other airports HERMES is and what will be its future 
availability, if any, to users other than CAA/NATS. 

With respect to detailed airspace simulations, 3D models hold an inherent 
advantage over node-link models, with respect to flexibility. This is 
especially true when it comes to evaluating concepts, such as Free Flight, 
which give airspace users the freedom to select their own optimized flight 
paths. Node-link models are almost completely unadaptable to such an 
environment. This means that TAAM and RAMS are the two models of 
choice in this area. RAMS provides more features and flexibility than 
TAAM, but the latter seems to be better suited to the simulation of large 
regions of airspace, with multiple sectors, airports, etc. Cost (in the case of 
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TAAM) and availability (in the case of RAMS which can be accessed only 
by arrangement with Eurocontrol) are additional considerations. RAMS, in 
addition, requires a very specific type of platform (HP9000 series 700 
workstations). 

2.1.4 Collective Model Assessment 

Capacity and delay models, as a group, represent the most advanced area of 
airport and airspace operations modeling. Many of the models in Table 2.1 
are “second generation” ones, i.e., have been preceded by other similar 
models and have benefited from the experience gained from these earlier 
predecessors. The growing level of model specialization (e.g., the fact that 
models of the same entities, such as of runway systems, exist at several 
different levels of detail) is additional evidence of the relatively advanced 
state of maturity in this area. 

Extensive practical experience also exists with many of the models in Table 
2.1. There is, therefore, considerable confidence in the ability of capacity 
and delay models to generate quite realistic results. This is especially true, 
when these models are used, as they often are, to rank competing 
alternatives, i.e., to assess the performance of concepts or proposals in 
relative, not absolute, terms. Even in absolute terms, however, the 
accuracy of these models has improved considerably for certain types of 
metrics over the years. For example, runway system capacity can usually 
be estimated with an accuracy of ±5% with some of the existing models. 

Despite these positive developments, a number of important problems 
remain in this area. One is the problem of model misapplication: the user 
community is not sufficiently familiar with the range of models available 
and often uses the wrong model to address problems at hand. The most 
typical example is the use of a microscopic model (e.g., SIMMOD or 
TAAM or The Airport Machine) to address questions that can be answered 
much more quickly and at much lesser cost by a macroscopic or mesoscopic 
model. 

A more fundamental problem is the large amount of resources (model 
acquisition costs, training, data collection and, especially, input/scenario 
preparation) typically required for applications of microscopic and 
mesoscopic models. This is especially true of studies involving regional 
systems of airports and associated airspace. Reducing the level of effort 
and resources associated with the use of capacity and delay models should 
be an area of emphasis in future work. 

A third problem is the adaptability of existing models to new ATM 
concepts. Recent attempts to evaluate the benefits and costs associated with 
the concept of Free Flight have brought this problem to the fore vividly. 
Some models (e.g., the airspace part of SIMMOD) are almost completely 
unadaptable to a concept that allows each aircraft to select its own optimized 
flight path in 3D space due to their node-link structure. But even 3D 
models, such as TAAM, currently lack critical features (e.g., sufficient 
stochastic options, detailed representation of weather and winds) needed to 
evaluate essential aspects of the concept. One way to overcome such 
problems in the future is for the user community to prepare a detailed set of 
specifications for the features that capacity and delay models should include. 
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Existing models could then be improved to comply with these specifications 
or, if necessary, entirely new models could be developed. 

Finally, it should be noted that serious problems exist, with respect both to 
“validation” of existing models and to the comparability of the results 
obtained from them. With respect to the former, most validations against 
actual field data have been performed either for only the simplest measures 
of performance (i.e., flow rates past certain waypoints) or under “mild” 
operating conditions. Few validation tests have been performed under 
conditions when airports/airspace operations are severely strained, for 
example when aircraft delays are of the order of one hour or more. The 
basic reason for this is that field data in such cases tend to be seriously 
“contaminated”, e.g., it is difficult to identify what delays are due to what 
causes; many flights may also be canceled or postponed under such 
circumstances, thus altering the initial capacity/demand relationships 
assumed by the models. As to the problem of comparability of results, 
there have been very few instances when two or more different models were 
tested with exactly the same data sets. Different models also “massage 
input data differently and may use different aircraft performance datasets 
(for the same aircraft type) thus further complicating the task of comparing 
results of different models. 

2.1.5 Recommended Model Toolkit 

Table 2.2 shows a recommended toolkit of capacity and delay models which 
can be put together in the short run, after only relatively limited additional 
model development effort. As indicated the toolkit should include one or 
more models at each different level of detail. The “contents” of this toolkit 
could be modified in the future, as the outcome of several other ongoing 
model development efforts becomes more clear. 

Table 2.2: Recommended “Toolkit” of Analytical and Fast- 

Time Simulation Models of Capacity and Delays 



Scope of Model 

Level of Detail 
(type of study) 

Aprons and 
taxiways 

Runways and final 
approaches 

Terminal area 
airspace 

En route 
airspace 

Macroscopic 


Enhanced Airfield 
Capacity Model* 
DELAYS* 



Mesoscopic 


NASPAC 

or 

FLOWSIM 

Microscopic 

TA AM 
or 

SIMMOD (airport)+ RAMS (airspace) 


The first macroscopic model in the toolkit is an analytical Enhanced Airfield 
Capacity Model that combines the best features of the LMI Runway 
Capacity Model with those of the FAA Airfield Capacity Model. Such a 
model, we believe can be developed quite easily and quickly. The second 
model is DELAYS which estimates efficiently airport delays based on the 
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airport’s demand profile and its capacity. The latter can be an externally 
specified input or can be computed by the Enhanced Airfield Capacity 
Model described above. 

We have not included AND in the toolkit, because it would be premature to 
do so before more experience is gained with this model. The same is the 
case with all the macroscopic en route airspace models listed in Table 2.1. 

The mesoscopic models listed in Table 2.2 (NASPAC or FLOWSIM) axe 
recommended -with reservations, for the reasons mentioned in Section 2.3 
above. Both have deficiencies at this point and may soon be superseded by 
better versions of FLOWSIM or extensions/spin-offs of NASPAC or by 
TMAC and ASCENT —when development of these two models approaches 
its final stage. For environments where serious en route delays, in addition 
to airport delays, are encountered, NASPAC is the choice over FLOWSIM, 
TMAC and ASCENT, because of the significant emphasis that NASPAC 
places on the en route environment. 

In the case of microscopic models, the airport portion of SEMMOD (the 
workstation version is strongly recommended over the PC version) is a 
viable, and in some respects superior, alternative to TAAM. A similar 
statement can be made about RAMS vs. TAAM, when it comes to airspace 
simulations. Thus, a combination of the airport portion of SEMMOD with 
RAMS may provide an alternative that offers an overall scope comparable to 
TAAM’s. An effort to interface seamlessly SIMMOD and RAMS in this 
manner (SIMMOD for airport surface, RAMS for airspace) is currently 
under way in Europe. 

Finally, three caveats are in order with respect to the recommended toolkit 
of Table 2.2. First, there is no implication that the models shown in the 
toolkit are fully satisfactory. They simply represent some of the best 
choices under the current state of the art. Second, it should be emphasized 
that the toolkit is only a “snapshot” of the situation at this moment. With 
much ongoing work on capacity and delay modeling, better alternatives than 
the ones recommended may emerge in the near future. Finally, there is also 
no implication that the models shown in the Table are currently compatible 
with one another. In fact, they are not: in the current absence of interfaces 
among them, they must necessarily be used as separate models with all the 
extensive effort that this implies in preparing the requisite model inputs and 
processing the associated outputs. 


2.1.6 Recommendations for Improvement 

Numerous steps can and should be taken to improve the state of the art in 
airport and airspace capacity and delay modeling. They can be summarized 
as follows: 

(a) Better integration of existing models: A toolkit such as the one outlined in 
Section 6 above should be assembled. This effort will certainly also spur 
development of interfaces that would assist the combined use of different 
models, whenever natural “affinities” between such models exist. Two 
most obvious examples of this type are interfaces between: (i) an enhanced 
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version of the LMI Airport Capacity Model and DELAYS (so that the 
former would compute runway system capacities which would then be 
“fed” into the latter to compute associated delays); and (ii) the airport 
module of SIMMOD and RAMS, so that airport capacity and delays could 
impact airspace operations and vice versa. 

(b) Development of common databases and utilities/tools: There is an urgent 
need to develop a set of common databases and of utilities/tools to support 
capacity and delay models. The common databases will facilitate use of the 
models and make their results directly comparable. The utilities/tools will 
address needs that arise consistently whenever such models are utilized The 
most pressing requirements are for databases and utilities/tools in the 
following areas: 

1 . Performance data for different aircraft types; 

2 . Airport geometry and airspace configuration data; 

3. “Standard day” scenarios, i.e., databases that contain complete data 
for selected days, such as detailed weather conditions at airports and 
airspace, airline schedules (including daily itineraries of individual 
aircraft), other traffic demands, delays recorded, etc.; 

4. Traffic generation/simulation tools (to simulate future traffic demand 
and generate hypothetical future airline schedules, including daily 
itineraries of individual aircraft, under alternative assumptions about 
future conditions); 

5. Weather generation/simulation tool (to generate statistically correct 
representations of airport weather, en route weather or regional 
weather). 

(c) Short-term model enhancements: Several of the macroscopic and 

microscopic models reviewed can be significantly improved in the short 
term with modest to significant effort. Most mesoscopic models reviewed 
(NASPAC, TMAC and the Draper Testbed) are currently in various stages 
of transition and it is premature to recommend further modifications to 
them. Examples (listed in an order corresponding to the level of effort 
required) include: 

1 . Enhanced version of an analytical capacity model that combines the 
best features of the LMI Runway Capacity Model and the FAA 
Airfield Capacity Model; 

2. Addition of various input and output features to AND; 

3. Addition of more stochastic features and conflict resolution 
capabilities to TAAM; 

4. Improved version of SIMMOD with emphasis on user interfaces, 
error diagnostics and facilitation of scenario preparation. 

(d) Medium- and long-term model development: Existing models will 

undoubtedly be succeeded by new and better models in the future. The 
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principal distinguishing feature of these models, compared to existing ones, 
will probably not be any major changes in their internal logic, but rather the 
application of advanced software engineering technology that would 
improve usability and robustness and reduce the cost of model-supported 
studies. The process of future model development would be greatly 
facilitated by the detailed specification of user requirements. Such 
specifications should be prepared with broad participation from the user 
community, so that the interests of civil aviation authorities, all types of 
aircraft operators, large and small airports, etc. will be taken into account. 
Model specifications should not be limited to microscopic models, but 
should also address user needs for macroscopic and mesoscopic models as 
well. 

Another desirable feature of future models would be a set of diagnostic and 
optimization capabilities (see Section 6 above). 
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2.2 


Model Reviews 


2.2.1 LMI Runway Capacity Model 

(5/6/96 ARO) 

1. Primary Model Category: 

Runway system capacity. 

2. Summary: 

The LMI Capacity Model is a generalized analytical and stochastic model for 
computing the capacity of a runway system. Its fundamental building block 
is a model that computes the capacity of a single runway, when the runway 
is used for arrivals only or for departures only or for mixed operations 
(arrivals and departures). 

A key feature of the LMI model is that it attempts to take into account 
explicitly probabilistic aspects of airport operations. So, for example, the 
approach speeds, the runway occupancy times and the delay in 
communication time between airport controllers and pilots are all 
incorporated into the model as random variables. Another important feature 
is that the model takes a "controller-based view" of operations. In this 
respect, it calculates the spacing between aircraft as they enter the common 
approach path such that, with reasonable confidence, no violations will 
occur later. 

The LMI Capacity Model is designed to compute the so-called "runway 
capacity curve", i.e., the set of points that define the envelope of the 
maximum throughput capacities that can be achieved at a single runway, 
under the entire range of possible arrival and departure mixes. Specifically, 
the model determines four points on the runway capacity curve. By 
interpolating between pairs of points with straight-line segments, one can 
then obtain (approximately) the full runway capacity curve. The four points 
are the following: 

Point 1: The "all arrivals" point, i.e., the capacity of the runway when it is 
used for arrivals only. 

Point 2: The "freely inserted departures" point which has the same arrival 
capacity as Point 1 and a capacity for departures equal to the number of 
departures that can be inserted into the arrival stream "for free", i.e., by 
exploiting large interarrival gaps without increasing the separations between 
successive arrivals (and, thus, without reducing the number of arrivals from 
what can be achieved in the all-arrivals case). 

Point 3: The "alternating arrivals and departures" point, i.e., the point at 
which an equal number of departures and arrivals is performed. This is 
achieved through an arrival-departure-arrival-departure-... sequencing, 
implemented by "stretching", when necessary, the interarrival gaps, so that 
a departure can always be inserted between two successive arrivals. 
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Point 4: The "all departures" point, i.e., the capacity of the runway when 
it is used for departures only. 

The LMI Capacity Model is still in its early stages of development and work 
on extending it to more than one runway is only beginning. (The version 
reviewed here is the one described in a draft report published in December 
1995 — see Section 12 below.) 

3. Input Requirements: 

Input parameters to the model include: the mix and number of aircraft types 
at the runway (pi); the length of the common approach path (D); the mean 
and standard deviation of the approach speed of each aircraft type [Vi, 
sd(Vi)]; the mean and standard deviation of the arrival and departure runway 
occupancy times [RAi, sd(RAi), RDi, sd(RDi)]; the miles-in-trail separation 
minima for all pairs (i,j) of aircraft types (Sij); the standard deviation of 
wind speed encountered by aircraft i on final approach [sd(Wi)]; the 
uncertainty in the position of aircraft i, quantified by the standard deviation, 
sd(Xi) of its location, Xi, along the final approach; and the mean and 
standard deviation of the communication time delay [c, sd(c)]. For 
departures, the model also uses the mean and standard deviation of the 
departure speed for each aircraft class and the minimum distance that 
departing aircraft must fly before turning. All the input random variables are 
approximated as normally distributed to facilitate the derivation of 
approximate expressions for the expected values and standard deviations of 
parameters of interest. 

4. Outputs: 

Capacity of a single runway for the four operating conditions (Points 1, 2, 3 
and 4) described in Section 2 above. Capacity is defined here as the number 
of operations that can be carried out on a runway with 95% confidence in 
the presence of continuous demand. (Note that, although related, this 
definition is different from the usual definition of "maximum throughput 
capacity"; the latter is simply the expected number of operations that can be 
carried out in the presence of continuous demand.) 

5. Major Assumptions: 

As noted, the LMI capacity model assumes, for computational purposes that 
all its input variables are normally distributed with known expected values 
and standard deviations. The model also uses a new definition of capacity 
("the number of operations that can be carried out in one hour with 95% 
confidence"). The model assumes that the "double occupancy rule" (two 
landing aircraft should not be on the same runway at the same time) should 
be maintained 98.7% of the time. 

6. Computational Characteristics: 

The LMI Capacity Model runs on a PC and requires no significant 
computational features. Versions of the single runway model have been 
prepared in both Pascal and C. The Pascal code is given in Appendix A of 
the document referenced in Section 12 below. The model uses a GUI, in the 
form of a Lotus spreadsheet, which allows the user to enter the model's 


24 




input parameters and displays the capacity curve implied by the current 
parameters, as well as the curve implied by a set of reference parameters. 

7. Modularity and Flexibility: 

The LMI Capacity Model is very easy to use and can potentially be 
incorporated as a module into models of more extensive scope, such as a 
model that would compute not only airport capacity, but also airport delays. 

8. Status of Model: 

The LMI Model has been developed only recently. A generalized model 
exists only for single-runway operations. Applications that extend the model 
in an ad hoc way to multiple runway operations have been carried out for 
the Detroit and Boston Logan airports. 

9. Extent of Model Validation: 

The single runway model has been partially validated through comparison 
of its results with those of the FAA Airfield Capacity Model. The ad hoc 
extensions to multiple runway operations (see Section 8 above) have been 
validated through comparisons with the capacities actually achieved at the 
Detroit and Boston Logan airports. 

10. Principal Applications: 

The LMI Capacity Model is currently being used in connection with the 
evaluation of the potential benefits of the NASA Terminal Area Productivity 
(TAP) Program. 

11. Model Availability: 

Arrangements for obtaining the code for the LMI Capacity Model can be 
made by contacting Dr. David A. Lee [dlee@mail2.lmi.org, (703) 917- 
7557] or Dr. Peter F. Kostiuk [pkostiuk@lmi.org, (703) 917-7427]. 

12. Information Base for Model Evaluation: 

Brief discussions with Dr. Peter F. Kostiuk and Dr. David A. Lee. 

Report: 

Earl W. Wingrove, David A. Lee, Peter F. Kostiuk, Robert V. Hemm, 
Estimating the Effects of the Terminal Area Productivity Program, Logistics 
Management Institute, McLean, VA. 

13. Summary Evaluation: 

The LMI Capacity Model is still not fully developed; it currently consists of 
a single runway model only with some ad hoc extensions to configurations 
with multiple runways. A more definitive evaluation of the model must 
therefore wait until completion of model development. However, the work 
done to date is very promising. The exposition of the single runway model 
is rigorous and the model's assumptions are clearly stated and explained. 
The model constitutes the first attempt after many years to develop another 
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analytical model of a probabilistic nature that would approximate well 
airport capacity under a wide variety of conditions. Its results, for the cases 
to which it has been applied to date are close to those observed in the field. 

A technical aspect that may require improvement in the future is the logic for 
inserting departures between arrivals on the same runway: for example, the 
model does not currently include a minimum distance separation between a 
departure and the following arrival at the time when the departure is set to 
begin its take-off roll; the model may also be inserting too many "free" 
departures between arrivals under certain conditions. The definition of 
capacity as "the number of operations that can be carried out in one hour 
with 95% confidence" is also unconventional and may result in lower 
estimates of capacity than those obtained under "the maximum throughput 
rate" definition of capacity. However, the LMI Capacity Model can be easily 
adjusted to provide estimates consistent with the "maximum throughput 
rate" definition. 

2.2.2 FAA Airfield Capacity Model 

(ARO; 7/29/96) 

1. Model Category 
Airport Capacity. 

2. Summary 

The FAA Airfield Capacity Model is an analytic computer model which 
calculates the (maximum throughput) capacity of a runway system given 
continuous demand. Given data on the runway configuration and operating 
procedures in use, it estimates the hourly capacity for 15 common airfield 
configurations ranging from a single active runway to four active runways. 
The model was initially developed in the late 1970s by a consortium that 
included Peat, Marwick, Mitchell and Company and McDonnell Douglas 
Automation and further modified by the FAA with support from the MITRE 
Corporation. It was last modified in February 1981. 

The model approximates single runway capacity using logic based on the 
fundamental concepts of the classical Blumstein model and its extensions. 
For more complex configurations it uses modules (models) that extend the 
analysis. Combinations of these base modules are then used for even more 
complex configurations. 

3. Inputs 

The input is a single text file with information on: runway configuration in 
use and the type of operations (arrivals, departures or both) assigned to each 
runway; aircraft mix on each runway; ATC separation requirements between 
operations on each runway; aircraft characteristics, such as final approach 
speed, runway occupancy times for arrivals and departures; length of final 
approaches; and weather inputs (ceiling and visibility) to determine flight 
rule conditions. Standard deviations of those inputs which are treated as 
random variables (e.g., runway occupancy times) are also required. 
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4. Output 


The model estimates the capacity per hour of the runway system for any 
specified arrival-departure ratio. Increments of 10% are used, if desired, to 
obtain a capacity "envelope" that consists of 11 points ranging from (100% 
arrivals, 0% departures) to (0% arrivals, 100% departures). 

5. Major Assumptions 

The FAA Airfield Capacity Model assumes that each of the 15 common 
configurations it can analyze can be viewed as a combination of four 
fundamental configurations: single runway, closely-spaced parallel 

runways, intermediate-spaced parallel runways and intersecting runways. 
For each of these four fundamental configurations it includes a module 
which computes that configuration's capacity. These modules are, in turn, 
based on a single- runway model that computes (i) the "all arrivals" capacity 
of the runway, (ii) the "all departures" capacity and (iii) the capacity of the 
runway when departures are inserted between arrivals, without reducing 
arrival capacity. The capacity for other mixes of arrivals and departures is 
then computed by interpolating among these three points. 

All random variables in the model are assumed to be normally distributed 
and a 5% probability of violation of separation requirements is used in 
determining spacing of runway operations, using these normal 
distributions. 

An implicit assumption is that taxiways and gates have little impact on 
determining airfield capacity. Another implicit assumption is that many 
airports operate with one of the fifteen runway configurations that the model 
analyzes and therefore the model will be useful. Both of these assumptions 
are substantially true in practice. 

6. Computational Characteristics 

The code is written in FORTRAN and is available for IBM machines, 
running on just 200 KB of memory. The User's Guide contains a full 
description of the methodology used and clear instructions on how to run 
the program. Provided that the relevant information is available, it takes little 
time to prepare the input file and run the program. No graphical interface is 
available. 

7. Modularity and Flexibility 

Almost all variables are specified by the user, so the model can handle most 
situations. Since the output is a simple number, using the FAA Airfield 
Capacity Model in combination with other software packages is 
straightforward. 

8. Status of Model 

This is considered a "mature" model, with no changes planned. 
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9. Extent of Model Validation 

Model validation took place in the 1970s. For selected configurations and 
cases, it was determined that the model provides adequately accurate 
estimates of airfield capacity. 

10. Principal Applications 

The model was used in the preparation of the FAA Handbook of Airport 
Capacity and Delay in 19(??). It has also been used in connection with a 
number of airport studies in the late 1970s and early 1980s, but its use 
seems to be limited today. 

11. Model Availability 

The FAA Airfield Capacity Model can be obtained from 

William J. Swedish, 

CAASD 

The Mitre Corporation, 

7525 Colshire Drive, 

McLean, Virginia 22102. 

12. Information Base for Model Evaluation 

The model was obtained and exercised at MIT. The following report was 
also reviewed: 

Upgraded FAA Airfield Capacity Model Supplemental User's Guide, 
William J. Swedish, The Mitre Corporation, McLean, Virginia 22102, 
February 1981. 

13. Summary Evaluation 

The FAA Airfield Capacity Model can be a useful tool for policy-level 
studies that require quick approximate estimates of the sensitivity of airfield 
capacity to various changes in the most common operating parameters, of 
airports (number and configuration of runways, aircraft mix, separation 
requirements, runway occupancy times, etc.) The model, however, can be 
improved significantly, particularly with respect to the logic for inserting 
departures between two arrivals on a runway. Because the model's logic is 
not particularly good in this respect, the model’s estimates of capacity for 
cases in which a runway handles approximately the same numbers of 
arrivals and departures will often not be particularly accurate. The FAA 
Airfield Capacity Model could also be strengthened by including in it some 
of the features that exist in the single-runway analytical capacity model that 
was developed recently by LMI (see review in this volume). In fact, a new 
model that combines the single-runway logic of the LMI model with the 
extension to multiple runways featured in the FAA Airfield Capacity Model 
could be a very useful tool that would provide instantaneous estimates of 
runway system capacity with limited data requirements. 


28 



2.2.3 AND: Approximate Network Delays 

(ARO; 7/15/96) 

1. Primary Model Category: 

System-wide model of airport delays 

2. Summary: 

AND (Approximate Network Delays) is a network queueing model 
developed at the MIT Operations Research Center, with software 
development support and database provided by the MITRE Corporation. Its 
objective is to analyze the impact of changes in airline schedules, traffic 
volume and airport capacity on flight delays on a national or regional basis. 
AND is an analytical tool and uses the DELAYS model as its engine for 
solving the differential equations that describe the distribution of delays over 
a network of airports, given flight schedules, aircraft itineraries and airport 
capacities. AND currently includes a database that encompasses the 58 
busiest airports in the United States and can thus be used to estimate, on a 
national scale, the benefits and costs of local or regional changes in airport 
infrastructure and in terminal area ATM technologies and procedures. 

3. Input Requirements: 

The inputs required by AND are: 

1 . The capacity profile of each of the airports of interest for the period of 
interest. (The typical period of interest in AND is one full day of 
network operations.) This capacity profile can be dynamic, i.e., the 
capacity may change at specified intervals of time. For example, if the 
period of interest is one day (midnight to midnight) and if the time 
interval specified is one hour, the capacity profile of each of the airports 
in the network is specified by an array of 24 numbers, the first number 
giving the airports capacity from midnight to 1 a.m., the second from 1 
a.m. to 2 a.m., etc. 

2 . The demand profile for arrivals and for departures at each of the airports 
of interest for the period of interest. The demand profiles are specified 
in exactly the same way as the capacity profiles (see above) and thus can 
be dynamic. 

3 . A complete schedule of flights that must be performed during the period 
of interest in the airport network of interest and the itineraries of each of 
the aircraft which will perform this schedule. For example, if Flight 
123 by airline XYZ will begin from Airport A and then visit 
successively Airports B and C, before it terminates at D, the scheduled 
times of departure from A, arrival and departure at B and C and arrival 
at D must be provided. If, moreover, the aircraft that performed flight 
123 will, after its arrival at D, be assigned to perform Flight 456, 
scheduled to depart from D at a later time, this also has to be indicated in 
the set of inputs to AND. (In the absence of data on aircraft itineraries, 
the AND model can be preceded by a pre-processor, prepared by the 
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MITRE Corporation, which processes airline schedules to infer such 
itineraries.) 

4. Outputs: 

The principal quantity computed by AND is the probability vectors 

P(i, t, k) that i aircraft will be in queue (waiting to land or to take-off) at 
time t at airport k. The values of these probability vectors are computed for 

all values of i (i = 0, 1,2, ) at time t, for t = 0, At, 2 At, 3 At, ... up to 

the end of the time period of interest for all the airports in the network. 
Using the P(i, t, k), AND then computes derivative measures of 
performance such as: 


• the expected queue length at each airport as a function of time; 


• the expected waiting time for operations at each airport as a function of 
time; 

• the total delay suffered by aircraft during the entire period of interest at 
each airport; 

• the fraction of aircraft delayed at each airport by more than X minutes 
(e.g., 15 minutes) during the period of interest, where X is a user- 
specified value; --the part of the expected delay at each airport that 
can be attributed to local congestion and the part which is attributed to 
"upstream" delays, i.e., to congestion at airports visited earlier in the 

day. 

5 Major Assumptions: 

The AND model makes two fundamental assumptions: First, it does not 
deal at all with delay due to en route airspace congestion, assuming 
implicitly that the great majority of delays in the ATM system is due to 
airport and terminal area congestion. This assumption is true in certain 
ATM environments (such as the United States) but false in others (e.g., in 
Western Europe, where a substantial amount of air traffic delay is caused by 
lack of en route sector capacity). 

Second, AND assumes that airports in the network under study are "weakly 
connected" meaning that no airport receives more than approximately 25% 
of its flights from any other single airport. This condition is necessary if the 
methodology used by AND is to be valid (see Reference (2) under item 12 
below) and is indeed true for practically all major commercial airports in the 
world. 

AND makes no distinction between arrivals and departures and treats all 
airport operations as demands that are served according to a first-come, 
first-served queue discipline. However, the effects of variations in the 
traffic mix (e.g., a high percent of arrivals during any particular hour) can 
be captured by adjusting accordingly the capacity of airports to reflect these 
variations. 
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Two additional assumptions of a more technical nature are due to the use of 
the DELAYS model (see review of DELAYS) as the "engine" of AND. 
Specifically, it is assumed that: demand at each airport can be approximated 
by a non-homogeneous Poisson process (i.e., demands occur at random 
instants with a demand rate that varies over time); and the service time per 
operation can be approximated by a k-th order Erlang random variable, with 
expected value (which may change over time) and standard deviation equal, 
respectively, to the corresponding (observed or estimated) expected service 
time and standard deviation of service time at the airport. (The appropriate 
order, k, of the Erlang random variable is determined by the relative 
magnitude of the expected service time and standard deviation of service 
time.) 

Finally, in propagating delays through the network of airports, AND 
assumes that the delay suffered by each airport operation is equal to the 
expected value of the delay at the time when that operation is scheduled to 
take place. (For further discussion, see References (1) and (2) under item 
12 below.) 

6. Computational Characteristics: 

AND is currently implemented in two versions, a serial model and a parallel 
model, both of which run on SUN SPARCstation 10 workstations. The 
parallel version exploits networks of workstations to speed up model 
execution by a factor of approximately 2. A typical execution time for a run 
involving a complete day of operations (about 50,000 landings and take- 
offs) at the 58 principal commercial airports in the United States takes 
approximately 20 minutes on the serial version (and approximately 10 on 
the parallel). 

AND runs with a mouse-driven GUI, through which the user can select 
different scenarios for execution, create new scenarios or modify existing 
ones. An Editor is included with the GUI to facilitate the modification of 
the capacity profiles of the airports in the network, if desired. A map 
display facilitates the selection of airports to be included in the network 
being studied. 

7. Modularity and Flexibility: 

The AND model is modularly designed in the sense that the DELAYS model 
which serves as AND's "engine" can be easily replaced, if desired, by 
another model that computes delays at any given airport. The number of 
airports in the network can be easily adjusted and can range from 2 to 58, at 
this point. 

8. Status of Model: 

The current version of AND is a fully-developed working prototype that, 
while containing all the fundamental eventual capabilities of the model, can 
still be significantly improved through the addition of several significant 
features that would enhance its applicability. A plan for such improvements 
exists. 
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9. Extent of Model Validation: 

A comparison has been conducted at MITRE between the results of the 
AND model and those of NASPAC. A set of tests involving a network 
containing many of the busiest airports in the United States, indicates that 
when NASPAC is used with all its features, NASPAC and AND give very 
similar results. 


10. Principal applications: 

The AND model is still an experimental tool and has not been used to date in 
specific applications. 


11. Model Availability: 

The model is not transportable at this point. Arrangements for its use can be 
made either through MIT (Professor Amedeo R. Odoni, Room 33-404, 
MIT, Cambridge, MA 02139, USA [(617) 253-7439, fax: (617) 253-7397, 
odoni@mit.edu]) or through MITRE (Dr. Andrew Haines, CAASD, The 
MITRE Corporation, 7525 Colshire Drive, McLean VA 22102, USA [(703) 
883-6714; haines@mitre.org]). 

12. Information Base for Model Evaluation: 


The following documents describe the logic of the AND model: 

1. Malone, Kerry (1993) Modeling a network of queues under 
nonstationary and stochastic conditions, S.M. Thesis, Operations 
Research Center, Massachusetts Institute of Technology, Cambridge, 
MA. 

2. Malone, Kerry (1995) Dynamic queueing systems: behavior and 

approximations for individual queues and networks, Ph.D. thesis, 
Operations Research Center, Massachusetts Institute of Technology, 
Cambridge, MA. 


13. Summary Evaluation: 

The AND model is the first analytically-based (not simulation) model that 
provides a fast, and flexible tool for delay analysis in a network of airports. 
It is designed for supporting policy analyses that require approximate 
estimates of system performance under a broad range of alternative 
assumptions. Because it is an analytical model (and thus requires but a 
single run to compute the probability distribution of flight delays for any 
given set of capacity and demand conditions) AND can outperform 
considerably, in terms of computational efficiency, existing national- scale 
simulation models in addressing issues related to the propagation of delays 
in the system of airports and to the national or regional delay impacts of 
changes in airline schedules, in airport demand levels and in airport 
capacities. The model is macroscopic and reflects the dynamic and 
stochastic nature of ATM/airport operations. 
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The model disregards completely delays which are due to congestion of en 
route airspace and it is thus more appropriate for ATM environments (such 
as the United States) where the great majority of air traffic delays is 
associated with airport congestion. AND also cannot capture the impact on 
the distribution of delays among airport users of air traffic control strategies 
that would assign priorities to certain types of operations (e.g., arrivals) 
over others (e.g., departures). It can, however, estimate the aggregate 
effects of such strategies. 

The model is still an experimental tool, as it is not transportable and lacks a 
number of desirable features that would facilitate its use and the preparation 
of certain of its inputs. If these features were added, AND would constitute 
a very competitive alternative to system-wide simulation models, such as 
NASPAC and FLOWSIM, for many types of policy-level studies. 

2.2.4 THE AIRPORT MACHINE 

Model Review (EMF 10/96, ARO 7/96) 

1. Primary Model Category 

Airport capacity and delays. 

2. Summary 

The Airport Machine is a tool for simulating in detail all aspects of airfield 
operations (including runways, taxiways and apron areas). Its principal 
measures of performance (and outputs) are flows and throughput capacity 
on the airfield per unit of time, and delays experienced at the various airfield 
facilities. It is based on a node-link structure similar to that of SIMMOD, 
and covers all aircraft activities from a few minutes before landing until a 
few minutes after take-off. This commercial software package was 
developed by Airport Simulation International (ASI). 

The Airport Machine relies on high-level-of-detail network representations 
of airfields. Traffic moves along a network of links and nodes with each 
link being able to accommodate a single aircraft at a time. Whenever two 
aircraft converge on the same link, the operating strategies programmed into 
the model determine which of the two candidates will occupy that link first 
and which will incur delay. 

Competing models include TAAM, SIMMOD and HERMES. 

3. Input Requirements 

The airport under study needs to be entered into the tool as a node-link 
network. Other inputs include schedule files, airport structure and ATC 
procedures. Aircraft types and wind information can also be model inputs. 
Up to eight aircraft types (user defined) and their characteristics can be 
specified. Control actions may either be entered manually in real time, as the 
simulation is being performed, or coded as a rule-base to be executed 
automatically. 
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4. Outputs 

The Airport Machine is equipped with a good graphical interface which is 
very useful for model calibration and validation purposes. The post- 
processor computes flows and delays at specific locations, identifies 
potential bottlenecks, and produces flow/delay graphs. 

Examples of information available include: numbers for arrival and 

departures for specified periods of time; gate occupancy times; statistics on 
towing operations; number of occupied gate positions; number of aircraft in 
the various airport queues. 

5. Major Assumptions 

The Airport Machine assumes a node-link structure for aircraft operations. It 
begins simulating operations as arriving aircraft reach the outer marker and 
stops immediately after take-off. It assumes that take-off operations are 
independent from the eventual route taken by the aircraft past the fix, so that 
no airborne trajectory is shown. This has been reported as a problem in 
some cases. 

The Airport Machine can perform only single-airport studies. The flight 
schedule includes information about flight routes, aircraft class and parking 
positions. Average taxi time is "minimized" by default by The Airport 
Machine. 

6. Computational Characteristics 

The Airport Machine runs on a standard PC (MS-DOS) plus a graphics 
card. Two screens are necessary, one for text editing and one for graphics 
display. Memory requirements are 4Mb of RAM. The source code is not 
provided. The code was originally written in Pascal. 

The support and documentation are both reportedly very good. 

A typical run time for a major and very busy airport takes about 10 minutes 
for 24 hours of traffic. 

The startup effort is about 2 to 4 weeks for people with prior exposure to 
simulation tools. The user interface is reportedly very good. 

7. Modularity and Flexibility 

The Airport Machine is a closed-architecture software system. An object 
oriented version is planned for future release. 

8. Status of Model 
Mature. 
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9. Extent of Model Validation 

The model has been used in numerous airport studies by now and can be 
considered validated under a wide range of conditions. Users report good 
agreement of model outputs with field observations. 

10. Principal Applications 

Numerous applications at many airports in the United States and Europe. 
For instance, the model was used recently in studies of alternative strategies 
for increasing capacity at Boston and Frankfurt airports. 

11. Model Availability 

The Airport Machine is available from Airport Simulation International, 
Inc.. The Airport Machine is licensed to users on an airport-by- airport 
basis. The price is about $20K for the first license and about $10K for each 
additional airport. Contact Airport Simulation International, Huntington, 
NY 11743, USA. 

12. Information Base for Model Evaluation 

Interview on January 9, 1996 with: 

Ingrid Gerdes, (49) 531 295 2279, (ingrid.gerdes@dlr.de), and Franz 
Knabe, (49) 531 295 2496, (fllg@brzsp7.bs.dlr.de), 
both from DLR. 

Discussions with Dr. Joline 

Discussions with several model users. 

13. Summary Evaluation 

The Airport Machine is a commercial product to evaluate airport capacity 
and delays. It is intended to support detailed design-level studies, offering 
"fine granularity" simulation of airport surface operations. It is a mature, 
quite user-friendly software package that has been used extensively and 
whose results have been validated. Users must undergo a significant 
amount of training and the cost of acquiring the model is considerably 
higher than that of SIMMOD. On the other hand, the current user interface 
of The Airport Machine is superior to that of SIMMOD. 

2.2.5 SIMMOD 

(3/2/96; ARO) 

1. Primary Model Category: 

Airfield and terminal airspace models. Secondary area: en route and regional 
airspace models. 
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2. Summary: 


SIMMOD can be used to simulate in detail: a full individual airfield 
(including runways, taxiways and apron areas); an airfield and its associated 
terminal airspace; a regional system of airports and the associated airspace; 
or, a regional volume of airspace. Its principal measures of performance 
(and outputs) are aircraft travel times, flows and throughput capacity per 
unit of time, delays and fuel consumption. 

SIMMOD relies on high-level-of-detail network representations of airfields 
and airspace. Traffic moves along a network of links and nodes with each 
link or node (depending on whether airspace or aiiport surface operations 
are being modeled) being able to accommodate a single aircraft at a time. 
Whenever two aircraft converge on the same node or link, the operating 
strategies programmed into the model determine which of the two 
candidates will occupy that node or link first and which will incur delay. 
Aircraft paths on the network are either specified by the user for every 
origin-destination pair or determined internally by the model according to a 
shortest-path (Dijkstra) algorithm. 

Much of the effort associated with setting up a SIMMOD simulation is, in 
fact, expended in developing the airspace and/or airfield network on which 
the traffic will move. For example, if a fan or trombone pattern is to be 
utilized to increase the efficiency of approach spacing and sequencing, all 
the possible alternative paths in the fan or trombone must be explicitly 
"programmed" as part of the network representation. 

SIMMOD has several options for simulating probabilistic events and can 
provide highly detailed output statistics down to the individual aircraft level. 

Competitive models are TAAM and, for airspace simulations only, RAMS. 

3. Input Requirements: 

The principal input requirements are the specification of the network 
structure for the airfield and/or airspace simulated and the description of the 
traffic that will move on this network, including flight paths and paths 
between gates and runways. To partially automate the tedious process of 
developing such networks, one can use a digitizer to trace the network of 
runways, taxiways and taxilanes from an airport layout map. Such an 
approach reportedly reduces the amount of time necessary to set up a 
network representation for a typical major airport to approximately 2 days of 
effort. It is also possible to use flight plans to generate the route network on 
which a SIMMOD airspace simulation will be based. SIMMOD includes a 
database with performance characteristics for 19 types of aircraft. A 
recently-added SIMMOD capability developed by Virginia Polytechnic 
Institute & State University (Virginia Tech) checks the network 
specifications of airfields provided by the user to ascertain conformance 
with FAA standards for separations between runway/taxiway and 
taxi way/taxi way centerlines, runway exit curvatures, etc. 
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4. Outputs: 


SIMMOD provides highly detailed statistics on each aircraft simulated. 
Outputs can be obtained on: aircraft travel times; traffic flows past specified 
points; throughput capacity per unit of time; delays by time of day and 
location on the airfield or in airspace, along with the immediate reason for 
each delay; and fuel consumption. 

5 Major Assumptions: 

The principal restrictive assumption in SIMMOD is that traffic must move 
on a pre-specified network of nodes and links according to pre-specified 
operating strategies or "rules of the road". In terms of conflicts between 
aircraft paths, SIMMOD is essentially a 1-dimensional model, checking for 
conflicts along the aircraft’s longitudinal path only, with no possibility of 
checking for lateral or vertical separation violations. 

6. Computational Characteristics: 

SIMMOD is written in SIMSCRIPT II.5 with a pre-processor and post- 
processor in C. It can be run on a personal computer, but for large 
applications a workstation (Sun or HP) is recommended. A 500 MB hard 
drive is required as well as a tape drive. Operating system: Unix or DOS. 
The SIMMOD software includes the HOOPS graphics card. 

As an indication of speed of execution, a simulation of 24 hours of 
operation at a major airport takes about 3-5 minutes (single run). 

7. Modularity and Flexibility: 

Ongoing efforts at Eurocontrol and CAA are aiming at developing a data 
interface (SIMBUS) so that RAMS and SIMMOD can be operated serially, 
with RAMS bringing aircraft to the final approach and SIMMOD picking 
them up there to simulate airport operations (and conversely for departing 
aircraft). Another area of interest at CAA is the development of a capability 
to specify externally the operating strategy in use at an airport or section of 
airspace and have SIMMOD execute this strategy in simulating operations. 
Currently such strategies must be programmed as part of the logic of the 
model; changing them requires a major effort. 

SIMMOD can be linked to the Integrated Noise Model (INM) so that the 
noise impacts of airport operations can be estimated. 

8. Status of Model: 

SIMMOD is a mature model, having undergone many revisions and 
improvements over a period of more than 15 years. Funding does not 
currently exist in the FAA for additional development of SIMMOD. The 
FAA recognizes the value of SIMMOD and is considering new funding 
methods to ensure SIMMOD's future growth and development. One 
proposed funding scenario involves bringing SIMMOD under the umbrella 
of the FAA's proposed Aviation Operations Research Center of Excellence 
(COE). 


37 


9. Extent of Model Validation: 

The ATAC Corporation conducted a validation study of SEMMOD in 1988 
(see Bobick, J. C., "Validation of the SIMMOD Model," ATAC 
Corporation, Mountain View CA, Contract No. DTFA03-85-C- 00043). 
The ability of the model to provide realistic results under quite complex 
operating conditions has been confirmed repeatedly in a number of airport 
and airspace simulation studies. 

10. Principal Applications: 

SIMMOD is possibly the most widely utilized airport and airspace model in 
the world today, with about 300 registered users worldwide, 50-100 of 
whom are believed to be currently active. The model has also been the 
beneficiary of significant support and promotion by the FAA over the past 
decade. 

The great majority of applications to date have dealt with the capacity and 
delay impacts of a variety of operational alternatives at airports. More 
recently, several studies dealing with reconfiguring regional or terminal 
airspace to reduce delays, reduce fuel consumption or improve operational 
efficiency have also utilized SIMMOD. 

11. Model Availability: 

SIMMOD is available at a nominal cost from the FAA (about $1,500 for the 
workstation version, about $400 for the PC version). Several companies in 
the United States (ATAC, CACI, SDT) offer training courses, typically 
one-week long, and/or provide software support for SIMMOD. 

Contact persons in the FAA are Tony Vanchieri ((202) 358-5198, fax (202) 
358-5543, avanchieri@mail.hq.faa.gov ) and Steve Bradford ((202) 358- 
5234, sbradford@mail.hq.faa.gov). 

12. Information Base for Model Evaluation: 

Interview with Steve Bradford on 12/18/95. 

Informal discussions with several users in the United States, Europe and 
Australia. 

Review of a draft report (October 1995) by DLR on an extensive series of 
simulation experiments at Frankfurt airport and terminal airspace. 

Review of the following documents: (i) Federal Aviation Administration, 
SIMMOD Data Input Manual, 1989; (ii) Federal Aviation Administration, 
SIMMOD Information Brief, 1989; (iii) Federal Aviation Administration, 
SIMMOD Reference Manual, Office of Operations Research (AOR-200) 
1989. 

13. Summary Evaluation: 

In the hands of a skilled user, SIMMOD is possibly the most powerful 
existing tool for "fine granularity" simulation of airport surface operations. 
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allowing for arbitrarily high levels of detail (e.g., simulation of push-back 
operations, gate occupancies, de-icing procedures, etc.). Several airport 
studies conducted with SIMMOD to date illustrate this point. 

The principal perceived weakness of SIMMOD is that it is a "labor 
intensive" model whose users must undergo a significant amount of 
training. Moreover, to avoid several potential pitfalls, SIMMOD users must 
have a very good understanding of ATM and airport operations. For 
example, because SIMMOD is essentially a one-dimensional model (i.e., it 
can check for conflicts between aircraft only along the paths traced by the 
elements of a network) care must be taken so that the network structure on 
which the traffic moves is based on sets of nodes and links with sufficient 
lateral and vertical separations to avoid the presence of undetected conflicts 
during the simulation. 

Another difficulty in SIMMOD is the modeling of dynamic rerouting of 
aircraft to simulate the ATM system's responses to local congestion 
problems. 

In summary, especially when its low acquisition cost is considered, 
SIMMOD may be the model of choice for high-level-of-detail airport 
simulations, with TAAM the principal competitor. The model's steep 
"learning curve" should, however, be recognized. For airspace studies, 
both RAMS and TAAM may be better alternatives at this point. For the 
specific case of evaluating the Free Right concept in en route, transitional 
and terminal area airspace, an important limitation is the pre-specified 
underlying network structure on which traffic is restricted to move in the 
SIMMOD model. 

2.2.6 TAAM: Total Airspace & Airport Modeller 

(5/14/96, KK) 

1. Primary Model Category 
Full Air Traffic system simulation. 

2. Summary 

TAAM (Total Airspace & Airport Modeller) is a large scale detailed fast-time 
simulation package for modeling entire air traffic systems, developed by 
The Preston Group (TPG) in cooperation with the Australian Civil Aviation 
Authority (CAA). 

TAAM can be used as a planning tool or to conduct analysis and feasibility 
studies of ATM concepts. TAAM can simulate most ATM functions in detail 
and can provide scenario generation for real-time ATC simulators. The 
simulations cover the entire gate to gate ATM process, generally in more 
detail than competing models. 

A TAAM simulation consists of a collection of user provided data relevant 
to the problem at hand and its modeling requirements. TAAM takes as input 
the air traffic schedule, environment description, aircraft flight plans, air 
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traffic control and output control rules. It uses them in performing airport 
and airspace usage, conflict detection and resolution, and aggregate metrics 
calculations with its internal algorithms and user defined rulebases. 

TAAM modules include an interactive graphical fast-time simulation tool 
which provides the user with a 2D or 3D view of the airpace or airport; a 
real-time air traffic monitoring tool with simulation capability; and a 
reporting tool which can be used to generate graphs and tables from data 
generated by the simulation. Simulations can be interrupted and restarted 
and key aspects of the model, such as conflict resolution and airport 
resource usage are controlled by rulebases which may be edited by the user 
during a simulation run. 'Live' graphical display of the simulation can be 
selected and customizable reporting is available. The simulation can also be 
run unattended in batch mode, with no graphics. During the simulation, 
statistics are gathered by the reporting program and written to a report file. 
This file is used by the Report Presentation Facility to construct the text and 
graphical reports desired by the user. 

Competing models: ASIM, SIMMOD, RAMS. 

3. Input Requirements 

As TAAM is a large scale simulation of an Air Traffic system, 
comprehensive input data files describing the entire Air Traffic system are 
needed. The level of detail can be varied for better modeling of critical areas. 
The inputs are the following: 

• Airport Descriptions 

• Airspace Route and Sector Layouts 

• Geographical Features 

• Air Traffic Control Rules 

• Airport Usage Rules 

• wake turbulence and other standards 

• SIDs/STARs/route selections etc. 

• Traffic Timetables 

• Aircraft Trajectories and Routes 

• Aircraft Performance Characteristics 

• Conflict Detection and Resolution strategies 

Default input files for a large proportion of these are available. Most data 
entry for building the environment model and operation rules is interactive, 
and various data entry tools are available: 

• 2D/3D graphical editor (CAD tool) for entering and editing graphical 
data such as airport layouts, airspace sectors, etc. 

• Data entry and validation tool for entering and maintaining data such as 
waypoints, routes, etc. 
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Other data entiy tools e.g. a digitizer for digitizing paper maps, and an 
external data converter for importing maps in AutoCAD(TM) format and 
Jeppesen(TM) data. 

4. Outputs 

These are in general aggregated metrics and can be reported on system or 
sector wide basis. 

• System delays 

• Conflicts: counts by degree of severity, whether successfully resolved 
or not 

• Airport movements, delays, operations on taxiways and runways, 
runway occupancy 

• Airspace operation metrics such as usage of routes, sectors, fixes and 
coordination 

• Noise contours 

• Total fuel burnt 

• Costs: aggregate, fuel, non-fuel 

• Controller workloads 

• Individual Aircraft flight profiles 

• Scenario generation e.g. for real-time ATC simulators or other playback 

• "Show Logic" diagnostics which gives the operator an insight into 
TAAM's decision making process 

• Text messages (extent and content user selectable) which contain further 
details of TAAM events 

• Errors 

A 2D or 3D graphical visualization of the simulation can also be generated. 
The graphical output can be viewed in several windows simultaneously, 
each window having an independent 2D or 3D view with the scale ranging 
from 30 m to 40,000 km. 

5. Major Assumptions, Limitations 

Hazardous weather, or special use airspace cannot yet be modeled 
dynamically. Weather modeling was limited to winds aloft in sectors, but 
according to TPG the user can now input SIGMETs (severe weather 
advisories) and TAAM can determine which aircraft, and when, will be 
affected by these severe weather areas. Conflict detection and resolution is 
selectable but may not resolve all conflicts. 

6. Computational Characteristics 

Hardware: Sun SPARCstation 20, 75Mhz cpu with 288MB memory and 
two 1.05GB hard-disks. Minimum requirements depend on the size of 
simulation to be run. Speed of simulation is strongly dependent on the scale 
(flights/day) and computation time varies approximately with the square of 


41 




the number of aircraft(real + ghost) in the simulation. Depending on the 
hardware used and the options enabled, TAAM can simulate airspaces up to 
the size of the entire continental United States. On the machine described 
above, a 16,000 flights for a day simulation takes about 24 hours to 
complete. Capacity improvements continue to be made. 

TPG quotes the following benchmarks for the latest TAAM version: 

• 20,000 flights a day, conflict detection/resolution enabled: 17 hours on a 
typical SPARC20. 

• 35,000 flights a day, conflict detection/resolution disabled: less than 4 
hours on the same machine. 

Graphical visualization is available. The user can switch between 2D and 3D 
mode at will, and has full control over the view. Simulation runs can be 
seen from any angle, from 'God's eye' view to 'worm's eye' view. Zoom 
is continuous from looking at the whole world to a single aircraft, with any 
stage in-between. Screen dumps can be made of any view. The simulation 
can also be run unattended, with no graphics. The user has full control over 
the simulation; he can at any time stop the simulation, make changes to 
airport operation or various aspects of the airspace, and restart the 
simulation. 

7. Modularity and Flexibility 

TAAM is available as an executable with customizable input and output 
files. Rulebases of most aspects are reconfigurable and can be edited even 
during simulation runs. Linking with other programs is possible via input 
and output Files. Additional packages allow linking with other ATM 
programs such as the FAA's Integrated Noise Model. 

8. Status 

Version 2.x of TAAM is available with a number of optional modules 
Additionally, TAAM is available as TAAM Airport, TAAM TMA, and 
TAAM Enroute, with reduced range and functionality. 

9. Extent of Model Verification 

Comparisons with FAA studies on some aspects of new ATM concepts 
have been performed showing comparable results. The simulation model 
has been verified by many users on a variety of scenarios. Aircraft 
movement in 4 dimensions can be fine tuned to get within 3%-4% of actual 
aircraft profiles. The same accuracy can be obtained for airport movement 
rates and other characteristics. 

10. Principal Applications 

Complete system simulation of present and proposed ATM systems and 
concepts. For example comparison between system performance using ATC 
preferred routes and Great Circle routes. 
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TAAM has a broad user base and many studies have been conducted many 
over the last 4-5 years, ranging from adding a couple of gates to designing 
London TMA procedures to total redesign of national airspace. 

The principal areas of application have been: 

• Airport capacity (gate, taxiway, runway capacity) 

• Planning airport improvements, extensions 

• De-icing 

• Noise impact 

• Impact of severe weather 

• Design of terminal area procedures (SIDs/STARs) 

• Design of terminal area ATC sectors 

• Controller workload assessment 

• Impact of new ATC rules, e.g. reduced vertical separation 

• Systemwide delays 

• Cost/benefit studies 

11. Availability 

The software is available from: 

The Preston Group Pty Ltd. 

488 Victoria St. 

Richmond, VIC 3121, 

Australia 

12. Information for Model Evaluation 

Datta, K. and G. Schultz, "An Evaluation of TAAM for Free Flight 

Modeling", Draft Report, Sverdrup Technology Inc., NASA Ames 
Research Center Moffet Field CA 94035 

Hank Wojcicki; TAAM homepage at Embry-Riddle Aeronautical University: 
http://erau.db.erau.edu/~taam/taam.html 

Alexander Klein 

(principal inventor and author of TAAM) 
email: sak@tpg.oz.au 

13. Summary Evaluation 

TAAM is one of the large scale, high level of detail fast-time simulations for 
entire Air Traffic Systems. It is currently the most fully featured ATM 
simulation available and with further enhancement could be incorporated 
into a system of models for the evaluation of concepts such as Free Flight. 
TAAM is undergoing futher development, and The Preston Group is 
currently (5/14/96) working on version 3. 
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TAAM is a 4D flight path simulation and allows greater realism than mesh 
based simulations such as SIMMOD. It is possible to simulate dynamic re- 
routing, e.g. to avoid conflicts with other aircraft although it is not apparent 
whether it is sufficient to model complete Free Flight. Hazardous weather 
can be input as SIGMETs (severe weather advisories) and TAAM can 
determine which aircraft will be affected by these severe weather areas. 
Conflict avoidance capabilities are somewhat limited. Conflicts are detected 
by ghost aircraft flying the look-ahead time ahead on the prescribed flight- 
path. When TAAM evaluates a conflict avoidance action, it checks that the 
action resolves the predicted conflict between the given two aircraft, and 
does not lead to conflicts with other aircraft in the vicinity. If both 
requirements are not fulfilled, TAAM rejects the action and tries another 
one. TAAM cannot move more than one aircraft at a time and avoidance of 
one conflict can result in others that are not resolved. 

TAAM Users 

The following organisations are major users of TAAM [TPG]: 

Europe: 

DFS (German Federal Aviation Service) 

NATS / British CA A 

STCA (French Directorate General of Civil Aviation) 

Swisscontrol 

NLR (Dutch National Aerospace Laboratory) 

Aerospatiale 

Thomson-CSF 

USA: 

FedEx 

Lockheed Martin 

NASA 

Boeing 

Continental Airlines 
Embry-Riddle Aeronautical University 
FAA Potomac MCF 

FAA Southern Region / Crown Communications 
New York Port Authority 

Asia: 

ENRI, Japan (Electronic Naviation Research Institute) 

Airservices Australia (former CAA) 

CRC Research Institute (a subsidiary of Itochu) 


2.2.7 HERMES: HEuristic Runway Movement Event Simulation 
(10/96 EMF) 

1. Model Category 

HERMES is a parallel runway capacity evaluation tool. It may also be 
useful as a tower controller workload evaluation tool. 
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2. Summary 


HERMES is a fast-time simulation developed by the British Civil Aviation 
Authority/ National Air Traffic Services (CAA/NATS) to evaluate runway 
capacity and operations timing under current and future demand and with 
technological improvements. It can also be used to evaluate changes in 
infrastructure such as runway length modifications. While full airport 
operations including taxiing are simulated, HERMES puts greatest emphasis 
on runway operations. HERMES takes experimental recording of aircraft 
flight paths as input and the principal output is average delays. HERMES is 
effective in providing aggregate results and has been designed to account for 
the specific rules used at Heathrow for computing very accurate capacity 
estimates. HERMES is reportedly able to achieve an accuracy of 3-4 
movements/24hr, as compared to 12-24 movements/24hr for SIMMOD or 
TAAM. HERMES also provides detailed simulation of most events 
occurring during take-off and landing phases. 

Competing models include TAAM, SIMMOD, and The Airport Machine. 

3. Input Requirements 

The main required input is traffic recordings. HERMES runs on 4-D traffic 
information obtained from experimental observations. Other inputs include 
aircraft mix, exit points for each aircraft, times to cross runways and 
resulting cross-effects on runway capacity. Aircraft are classified by speed 
and vortex separation categories. Traffic generation may be based on 
published time tables or from input parameters defining required demand 
profiles. Additional inputs include simulation parameters such as number of 
simulation runs. Currently HERMES inputs are mostly based on 
Heathrow/Gatwick data. 

4. Outputs 

The main output of HERMES is a file containing average delays to all 
flights simulated. There is a post processor, written in C, and Excel Macros 
which consolidate the output files and produce delay statistics graphs. Other 
outputs include a log file which contains details of all actions performed by 
every aircraft in a given iteration. These CSV (comma separated variable) 
files are used for ad hoc analyses of the results. A simple text based 
graphics output is also available and is a useful debugging tool. 

5. Major Assumptions 

HERMES has been custom designed for Heathrow and Gatwick and the 
applicability of the software to other airports is undetermined. HERMES 
cannot model situations involving runway crossings. The model uses 
experimental trajectories and does not require transcription of experimental 
data into a specific formats such as the link-node structure of SIMMOD. 
Delays are simply propagated across flight trajectories depending on 
occurring events. Most flight parameters can be randomized. 
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6. Computational Characteristics 

Existing code has been written in C. It is a standard PC application. No 
specific graphics are necessary. Eight MB of RAM are necessary. 

A typical run takes about 10 minutes to complete. A typical simulation 
experiment will take approximately 1 to 4 weeks of staff time, depending 
upon how much analysis of the results is required. These timescales exclude 
the period required for direct observations of airfield operations, the data 
validation, and its entry into the simulation. 

General and technical information on HERMES can be obtained by 
contacting David Haydon (011-44-171-832-5601). 

The documentation includes file descriptions and a user manual. 

7. Learning Effort 

Unknown. 

8. Modularity and Flexibility 
Unknown. 

9. Status 

HERMES is used on a regular basis for evaluation of airport improvements. 
It is often upgraded. The current version is HERMES II. HERMES III was 
scheduled to replace HERMES II in March 1996. 

10. Extent of Model Verification 

HERMES is used on a regular basis and its output has been compared 
extensively with real data. The accuracy of HERMES is considered superior 
to SIMMOD. 

11. Principal Applications 

Capacity change estimates for infrastructure modifications at Gatwick and 
Heathrow airports. 

12. Availability 

HERMES is proprietary software owned by CAA/NATS. However, 
CAA/NATS has a cooperative agreement with the FAA and any contract 
awarded by the FAA can access HERMES. 

13. Information for Model Evaluation and Contact Points 

Interview with David Haydon and functional description document for 
HERMES II. 
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David Haydon 

Directorate of Operational Research and Analysis 
National Air Traffic Services CAA House 
45-59 Kingsway 
London WC2B 6TE 

Tel: Oil 44 171 832 5601 
Fax: Oil 44 171 832 6225 

14. Summary Evaluation 

HERMES is an operational tool used to evaluate airport delays for new 
configurations. While the model is currently intended for Heathrow and 
Gatwick operations, it might be applied to other airports as well. The main 
input for the model is real flight data, which increases complexity, but 
yields very accurate aggregate results. The need for aggregate results 
obtained from Monte-Carlo simulations implies quite long simulation times 
to achieve credible results. HERMES is an appropriate tool to study cases 
where delays are extremely sensitive to demand variations. 


2.2.8 NASPAC 

(ARO 9/30/96) 

1. Primary Model Category: 

System-wide model of air traffic flows and delays 

2. Summary: 

The National Airspace System Performance Capability (NASPAC) is a fast- 
time simulation model that may encompass large regions of airspace and a 
large number of airports. The simulation “flies” individual aircraft through 
daily itineraries (that may include landings and take-offs at a sequence of 
airports) and provides statistical reports on delays and flow rates observed. 
The model includes simplified representations of en route sectors, as well as 
of airports. Some graphical outputs by airport, sector or region can be 
provided. NASPAC was originally conceived as a macroscopic-level model 
that would support studies dealing with issues related to strategies for 
national airport investments and to policy for national and international 
ATM. However, much detail has been added to it over the years and it may 
actually be better suited today to answer questions of a more tactical nature, 
such as the effects on delays of alternative flow management strategies. 
Several variations and extensions of NASPAC have been developed in 
recent years by MITRE, for internal use. CENA in France has also 
developed a version (F-NASPAC) which is better adopted to the European 
ATM environment. 
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3. Input Requirements: 

The principal inputs to NASPAC, include: demand, in the form of a 

complete schedule of aircraft itineraries in the airspace region of interest (the 
demand includes both scheduled and unscheduled flights); capacities of 
airports and of other ATM resources, such as any modeled fixes and en 
route sectors; and aircraft performance data. 

4. Outputs: 

The main outputs of NASPAC consist of estimates of delay and of flows 
past given points ("throughput") in the system modeled. Delay is reported 
in the form of "technical delay" (defined as the local delay incurred at any 
specific point in the system) and of "effective delay" (defined as tthe 
difference between scheduled and actual times of events, such as the arrival 
or departure from a gate). 

5. Major Assumptions: 

The NASPAC simulation is essentially a deterministic one. Given a 
schedule of operations and a set of resource capacities, the model performs 
this schedule and then reports associated delays and flows. Modeling of 
resources is at a low level of detail, in keeping with the model's objectives. 
For example, an airport's capacity is a single number that represents the 
acceptance rate of that airport and is not concerned with gate capacity, 
taxiway capacity or the nuances of the runway configuration in use. 

NASPAC includes a module that attempts to infer the itineraries of 
individual aircraft from OAG-like airline schedules. This process is, of 
course, an approximate one. 

6. Computational Characteristics: 

The NASPAC simulation model is written in SIMSCRIPT II. 5 and its pre- 
processor and a graphics and report-generating post-processor in Fortran, C 
and Pascal. The model runs in a workstation environment (SUN 
Sparcstations). 

7. Modularity and Flexibility: 

The level of detail in NASPAC modeling can be adjusted to some extent to 
fit the needs of the study at hand. The pre-processor and post-processor 
consist of a large collection of programs that can be utilized according to 
need. 

8. Status of Model: 

NASPAC was originally developed by the MITRE Corporation for the FAA 
during the late 1980s. After several revisions, the model was transferred to 
the FAA. NASPAC has also been transferred by the FAA to a small 
number of national and international civil aviation organizations outside the 
United States, such as CENA (France) and Eurocontrol, where it is used as 
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a research tool, as well as for support of traffic flow management 
operations. 

The FAA has no current funding or plans for the further development of 
NASPAC. However, some model enhancements are taking place in 
connection with specific model applications. For example, CENA has 
implemented a number of model modifications that make NASPAC more 
adaptable and appropriate to the European ATM environment. 

MITRE has also developed recently at least two other models which can be 
viewed as simplified alternatives to alternatives to NASPAC. These are 
Quickpac andAJVlC (the Aggregate Modeling Capability). 

9. Extent of Model Validation: 

A number of NASPAC validation efforts have taken place over the years 
(see, e.g., Chemiavsky, Ellen A. et al., Validation of the National Airspace 
System Performance Analysis Capability Simulation Model, MITRE 
Report MTR-89W00170, May 1990). Agreement with field observations 
has been reported to be reasonably good. 

10. Principal Applications: 

NASPAC has been applied in a number of instances in the United States 
and in Europe. For example, the model was used to assess the impact on 
airline delays nationwide of the (then proposed) new Denver International 
Airport. It was found that the proposed airport would contribute to a 
substantial reduction of delays on a national scale. Some applications of 
NASPAC have been concerned with the impacts of alternative traffic flow 
management (TFM) strategies. The NASPAC database currently includes 
the entire National Airspace System in the United States with emphasis on 
the 58 busiest commercial airports. 

11. Model Availability: 

NASPAC is not a commercially available product, but access to it can be 
obtained through the FAA. Occasional NASPAC-based studies in the 
United Staes are carried out at FAA Headquarters (supported by CSSI), 
FAA Technical Center and the MITRE Corporation. NASPAC-based 
studies in Europe are performed by CENA (France) and Eurocontrol, which 
also have copies of the model. 

12. Information Base for Model Evaluation: 

Presentation by Anthony Zukas (MITRE) on 12/18/95. 

Interview with Steve Bradford (FAA) and William Weiss (CSSI) on 
12/18/95. 

Numerous informal discussions with NASPAC developers or users at 
MITRE, CSSI, FAA and CENA. 
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13. Summary Evaluation: 


NASPAC is the first model to be developed for the express purpose of 
studying the propagation of delays and congestion through a national or 
regional ATM system. It can be a useful tool, if utilized properly with a 
recognition of its strengths and limitations. For example, because the 
capacity of each airport in a national system can assume several different 
values, there is typically an enormous number of different combinations of 
airport capacity values that can materialize on any given day. Thus a very 
large number of "runs" of NASPAC, each with a different combination of 
airport capacity values would be needed to obtain good estimates of the 
mean delay values encountered in the system and of the typical range of 
these values (e.g., their standard deviation). 

Use of the model requires considerable training and significant resources in 
terms of both costs and personnel. Arrangements must be made with one of 
the organizations that operate the model. Extensive data are also needed, 
but databases have by now been assembled both for the United States and 
for pans of Western Europe to support many types of NASPAC studies. 


2.2.9 TMAC 


(Last update: 3/25/96 JKK) 

1. Primary Model Category 

Simulation tools to analyze flow management strategies and system level 
evaluation of alternative operational concepts. Tools were developed to 
support FAA concept exploration and development. 

2. Summary 

TMAC is a set of capabilities and thus more than a single model. It uses 
aircraft flight plans, dynamics, and traffic management strategy (e.g., free- 
flight, limited airborne holding) to determine conflicts and delays. 
Uncertainties in aircraft trajectory projections are also modeled to provide 
realistic inputs to traffic management logic. The user is able to interact with 
the models for concept development. TMAC is complex, intended to solve 
specific problems and not meant to be a generic modeling tool. It is not 
available outside MITRE. 

Competing models include SIMMOD, RAMS, NASPAC, TAAM, and 
FLOWSIM. 

3. Input Requirements 

Aircraft routes, flight plans, aircraft dynamics, ground delays, traffic 
management logic (e.g., free-flight, structured ATC, or airborne holding), 
airport capacity. 
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4. Outputs 

Travel times, delays, conflicts. 


5. Major Assumptions 

Assumes given airport capacities but no en route sector capacities. No 
conflict resolution algorithms are included. 


6. Computational Characteristics 


Platform: 2 - HP 755 workstations (one for Sybase, one for the model) 

Operating System: HP-UX 9.0.3 

Memory: 384 MBytes RAM, 2 GByte Hard Drive 

Software Requirements: Sybase 4.9.2, Vads (Verdix/Rational) 6.2, (Perl, 


C ADA). 

Documentation: No formal documents but adequate user’s guides reportedly 
exist. 

Startup Effort: High 

User Interface: Adequate (GUI) 

Typical Run Time: best case is 0.9 real time (i.e., slower than real time) 


7. Modularity and Flexibility 


TMAC is a compilation of several modules and building blocks but its 
complexity and focus on specific problems makes it difficult to generalize to 
other problems. The model is somewhat flexible in that it has been used to 
examine diverse traffic management strategies but is not available to users 
outside MITRE. 


8. Status 

Under continual improvement and use at MITRE. The focus has been on 
solving specific problems rather than the development of a more generic 
modeling tool. 

9. Extent of Model Verification 

Average 2-minute savings under free-flight determined by TMAC has been 
corroborated by a simulation using NASPAC and (independently) by a 
Delta Airlines study. 

10. Principal Applications 

Evaluation of traffic management strategies: limited airborne holding, free- 
flight vs. structured control, cooperative slot exchange, arrival flow 
management, airline schedule volatility, classification of weather day types 
for TFM. 

11. Availability 

Not available outside MITRE. Intended as an internal tool only. 
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Contact: John Pyburn, MITRE Corporation, (703)-883-5546, 

jpybum@mitre.org 

12. Information for Model Evaluation 

Presentation and interview with John Pyburn, MITRE, 12/18/95. 

13. Summary Evaluation 

TMAC is a complex, multi-element simulation and analysis tool intended 
primarily for use in evaluating traffic management strategies. Although it is 
intended primarily as a strategic concept analysis tool, its level of detail is 
higher than that of NASPAC. The user is able to enter flight plans, aircraft 
type, ground delays, and traffic management strategy. Outputs include 
travel times, delay metrics, and conflicts. There is no conflict resolution, so 
the model is unable to show the impact of conflicts on traffic flow. The 
model is not available outside MITRE. TMAC is being actively used at 
MITRE in a number of TFM studies and to support the refinement and 
evaluation of the future NAS concept of operations. 


2.2.10 FLOWSIM (FAA) 

(Last update: 3/6/96 JKK) 

1. Primary Model Category 

Model of traffic flow subject to airport capacity constraints. 

2. Summary 

FLOWSIM is a fast-time simulation of aircraft flow between major airports 
to determine delays and ripple effects induced by capacity constraints. The 
user enters flight plans from ETMS data, and FLOWSIM uses airport 
capacity models to determine delays. There is no simulation of en route 
operations: sectors are assumed to have unlimited capacity and aircraft are 
simulated by flight plan, not by dynamics. Airports have fixed capacity 
based on weather and configuration. Tactical and strategic studies can be 
conducted by using the traffic management editor to implement ground 
delay programs, miles-in-trail restrictions, or ground stops which then 
adjust the flight plan for simulation. 

Competing models include AND, NASPAC, and TMAC. 

3. Input Requirements 

Requires ETMS data for aircraft flight plans. A database of capacity figures 
for 38 major airports is included with the model. These capacity figures are 
based on FAA EPS (Engineered Performance Standards) information. 
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4. Outputs 

Delay metrics. The user can view delays as a function of airport and time. 

5. Major Assumptions 

All aircraft are assumed to follow pre-defxned flight plans: there is no tactical 
rescheduling. En route sectors have unlimited capacity. Delays are produced 
based on miles-in-trail restrictions and airport capacity constraints. 

6. Computational Characteristics 

Code exists (written in C++) of approximately 10,000 - 20,000 lines and is 
very fast. The flight profile modeler and the timing routine are very robust 
and have been ported to other models. Platform, software, and hardware 
requirements have not yet been determined. Documentation quality is 
currently in draft for the prototype version. 

Typical run time (for a complete 24 hr simulated period) is approximately 5- 
6 minutes. 

7. Modularity and Flexibility 

Extensive work would be needed to incorporate en route operations 
modeling and aircraft dynamics. The object structure for the flight profile 
model includes all characteristics of model sectors. . Actual interactions 
between aircraft has not been developed. The code is relatively generic 
because some routines have been ported to other models. 

8. Status 

The model is intended as an experimental tool, is a "first prototype", and is 
not mature. The FAA has not worked on further development for the last 2 
years and has no plans at this time to do so in the future. Metron, Inc. is 
utilizing and modestly improving the model. 

9. Extent of Model Verification 
Unknown. 

10. Principal Applications 

Strategic delay modeling given flight plans and airport capacity constraints. 
Specific applications are unknown. 

11. Availability 

Available through FAA, Metron, Inc., and ATAC. The primary constraint is 
that the model requires ETMS data. Contact: Steve Bradford, FAA, (202)- 
358-5234, sbradford@mail.hq.faa.gov 
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12. Information for Model Evaluation 
Interview with Steve Bradford, FAA, 12/18/95. 

13. Summary Evaluation 

FLOWS IM at this point is an experimental tool used to estimate flight delays 
as a function of aircraft flight plans and airport capacity constraints. The 
model has no provisions for aircraft dynamics or interactions between 
aircraft while flying. Flight plans must be specified in advance (using 
ETMS data) and can be changed while the model is running by using the 
traffic management editor to implement ground delay programs, miles-in- 
trail restrictions or ground stops which then adjust the flight plan for 
simulation. The model allows for the rapid simulation of flight plans to 
determine if ripple effects may occur among airports. The simplicity of the 
model (as compared to TMAC, for example) allows FLOWSEM to operate 
rapidly (approximately 5 minute run times). The short run time suggests that 
a number of different flight planning strategies can be evaluated quickly, 
although only in an approximate manner. The code is apparently generic 
because some routines have been ported to other models. 

2.2.11 ASCENT 


1. Primary Model Category 

Air Traffic Flow Management (ATFM) 

2. Summary: 

ASCENT (ATFM System Concept Evaluator for New Technologies) has 
been developed and implemented to evaluate the system-wide impact of new 
procedures, technologies, and improved infrastructure under existing or 
anticipated future approaches to ATFM. The model has been designed so 
that it can be used by a single analyst, requiring a minimum of overhead 
activity associated with defining and setting up scenarios and performing 
analyses. It is capable of evaluating candidate air traffic flow management 
approaches across a spectrum of scenario variations. Flight schedules 
(demand) and airport capacities (supply) have been determined to be the 
most significant defining factors for any given scenario. Tools have been 
created to allow user interaction in the creation of each of these scenario 
components. 

The current version of ASCENT contains: 

i) models for a national network of capacitated and non-capacitated 
airports; 

ii) algorithms for planning ground holds and for allocating mandated 
delay between the ground and the air; 

iii) algorithms for (airline) tactical planning of arrivals at airports; 

iv) a system level simulation of a day’s activities in the National 
Airspace System (NAS); 

v) database and analysis capabilities. 
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Supporting utility programs include: 

vi) models to simulate the evolution of airport weather and capacity; 

(vii) a tool for generating OAG-like demand schedules at airports. 

Once the set up of a test case is completed, the simulation of a day in the 
NAS is realized, and the resulting delays and other desired evaluation 
metrics are computed. When weather/capacity are modeled 
probabilistically, their realizations may not exactly match forecasts that may 
have been used by algorithms that plan for ATTM activities. If at some 
point during the simulated day, a (weather or capacity) forecast changes, the 
analyst can choose to exercise an algorithm to replan ground holds or select 
an algorithm to tactically resequence arrivals at a given airport, both on the 
basis of the current state of the system and the new forecast. The analyst 
can also run an N-day Monte Carlo simulation based on probabilistic 
capacity scenarios and travel times. 

ASCENT is a model whose capabilities overlap partially with those of 
NASPAC, TMAC and FLOWSIM. 

3. Input Requirements: 

In setting up a simulated test case, the analyst selects a flight schedule and 
an airport capacity scenario as inputs. One of a set of ground- 
holding/arrival slot allocation algorithms is selected to create planned aircraft 
ground holds and slot allocations for the day. Reductions in en route times 
due to free flight, reductions in airport ground delay times due to the 
improved ground traffic management or increases in effective airport 
capacity due to improved arrival sequencing due to, for instance, CTAS can 
also be selected or specified by the analyst. 

The input preparation process is assisted by the following files: 

Enhanced flight schedule file- includes the information found in an OAG 
schedule, arrival and departure bank information at hub airports, current 
planned aircraft itineraries, and the cost of delays and tardiness for each 
aircraft. 

Airport capacity profile file- includes both arrival and departure capacities 
for each possible capacitated airport operating configuration (an operating 
configuration includes the flight rules and the runways in use for arrivals 
and departures) 

Scenario file- specifies the network of capacitated airports and the 
probability distribution on the airports’ operating configuration for a given 
day. 

4: Outputs: 

ASCENT provides the scheduled, planned and realized itinerary for each 
aircraft in the flight schedule; these can be output as text files for analysis in 
a database. In addition, numerous statistical measures are available, filtered 
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by the user across airlines, airports, time periods, aircraft types, etc. Many 
of these outputs can be displayed through an extensive menu of windows. 

5. Major Assumptions: 

ASCENT assumes implicitly that terminal areas are the serious congestion 
points in the ATM system. It thus places its emphasis on modeling ATFM 
approaches and strategies, such as ground-holding and arrival slot 
allocation, designed to deal with terminal area problems. En route 
congestion, if any, is dealt with by simply increasing input en route travel 
times between airport pairs. ASCENT also utilizes simplified 
representations of terminal area decision support tools, such as CTAS and 
SMA. 

6. Computational Characteristics: 

ASCENT requires a PowerMac or equivalent clone running MacOS System 

7. The computational modules of ASCENT are written in ANSI C. For 
less than tens of thousands of flights, memory requirements range from 4- 
8MB; for tens of thousands of flights, memory requirements range from 8- 
12MB. The application and needed data files require less than 5 MB of hard 
disk space. The minimum required monitor resolution is 832 x 624, and the 
application can use effectively any additional monitor resolution. 

Software / compiler requirements: ASCENT is a stand-alone compiled 

application. 

Existing documentation: Minimal. 

Startup effort required: Low. 

User interface: Good. 

Typical run time: seconds to minutes 

7. Modularity and Flexibility: 

The code is very much object-oriented, even though it is written in C, not 
C++ and additional planning algorithms can be easily added. Input and 
output use simple text formats, providing straightforward integration with a 
variety of preprocessing and post-processing models. 

8. Status of Model: 

Development of ASCENT has taken place over a five-year period beginning 
in 1992, with major enhancements taking place during 1996. 

9. Extent of Model Validation: 

Validation to date has been limited to consistency testing, demonstration of 
capability to emulate alternative ATFM strategies and extensive sensitivity 
analyses. 

10. Principal applications: 

The model is intended to serve as a tool for evaluating the system-wide 
impact of new procedures, technologies, and improved infrastructure under 
existing or anticipated future approaches to ATFM 
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ASCENT has been used to date as a tool for (1) demonstrating conceptually 
the potential impacts of alternative approaches for allocating airport arrival 
slots, (2) exploring the performance of alternative ground-holding strategies 
and (3) investigating the sensitivity of ATFM performance to changes in 
various system parameters, such as airport capacity, variabilty of aircraft 
spacing, flight sequencing priorities, etc. 

11. Model Availability: 

The executable is available to at no cost to the NASA AATT Program; it is 
also available for academic research. All questions on access should be 
directed to Dr. Milton Adams (adamsm@draper.com) at Draper Laboratory. 

12. Information Base for Model Evaluation: 

Robinson, J. D. (1992). A Simulation Testbed for Flow Management 
Analysis in Air Traffic Control, CSDL-T-1148, C.S. Draper Laboratory, 
Master’s Thesis in Operations Research, MIT, Cambridge, Mass. 

Hocker, Guy A. (1994). Airport Demand and Capacity Modeling for Flow 
Management Analysis, CSDL-T-1200, C.S. Draper Laboratory, Master’s 
Thesis in Operations Research, MIT, Cambridge, Mass. 

Yu, Jung (1996). Airport Capacity and Regional Weather Modeling, 
CSDL-T-1271, C.S. Draper Laboratory, Master’s Thesis in Operations 
Research, MIT, Cambridge, Mass. 

Adams, Milton, S. Kolitz and A. Odoni (November 1996). Evolution 
Toward a Decentralized Air Traffic Flow Management System, CSDL-R- 
2767, C.S. Draper Laboratory, Cambridge, Mass. 

13. Summary Evaluation: 

ASCENT has the potential for becoming a very valuable testbed for ATFM 
concepts and strategies because it has several unique features: easy to use 
and designed for operation by a single analyst; many default inputs and a 
highly graphical interface that greatly facilitate the definition and preparation 
of scenarios and the performance of analyses; pre-programming of several 
generic ATFM strategies for the allocation of airport arrival slots, such as 
“first-scheduled, first-served”, “minimize delay costs”, “minimize costs 
over a network of airports”; stochastic and deterministic airport capacity 
forecasts that make it possible to evaluate the performance of ATFM 
strategies in the presence of uncertainty; and the availabilty of the demand- 
generation tool POAGG, for easily generating OAG-like hypothetical flight 
schedules for a network of airports. The principal weakness at this time is 
that the model is new, has not yet been tested adequately or validated and is 
not transportable due to lack of adequate documentation. 
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3.0 CONFLICT DETECTION and RESOLUTION MODELS 


3.0 REVIEW OF CONFLICT DETECTION AND RESOLUTION MODELS 
3.1.1 Definition 

Traffic conflicts between aircraft flying under an advanced air traffic 
management concept will affect overall system benefit, cost, and safety. To 
examine both the potential impact of conflicts and to evaluate candidate 
conflict resolution strategies, it will be necessary to develop and use 
specialized conflict models. These models can be roughly organized into 
three categories, shown in Figure 1. Aircraft trajectories must be generated 
based on a model of assumed parameters such as aircraft type, routing 
logic, etc. A conflict detection model then determines which of these 
trajectories result in conflicts. A model for conflict resolution produces 
performance metrics, such as accident rate, based on a given conflict 
resolution approach. In more detail, we have: 



Figure 1: Basic Conflict Model Requirements 


1. Trajectory Generation: The density (spatial or temporal) of conflicts is a 
predictor of the amount of intervention that will be required to maintain 
aircraft separation. Models of traffic flow are needed to determine the 
frequency and form of conflicts (e.g., the location, geometry, and number 
of aircraft involved in a conflict). Trajectory generation models may be 
developed specifically for conflict analyses or may be adapted from capacity 
and delay models (Section 2). 

2. Conflict Detection: Conflict probe algorithms must be developed to alert 
controllers and/or pilots that a conflict exists. These probes will use sensor 
and datalinked information such as aircraft position and intended path to 
determine if intervention is required. Models are needed here to determine 
the effectiveness (e.g., false alarm rate) of conflict probe methods. 
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3. Conflict Resolution: Once a conflict is detected, a method of resolving 
the conflict is needed. Models are required to determine whether proposed 
resolution methods are effective in maintaining separation and to determine 
the impact of the conflict on the overall traffic flow. Additionally, 
depending on the ATM environment at hand, human performance 
considerations during conflict resolution may need to be modeled (e.g., the 
controller’s ability to manage several aircraft at once). 

Different models may, of course, cover some or all of the aspects of conflict 
modeling shown in Figure 1 . For example, one model may only generate 
trajectories, while a different model may generate trajectories, estimate the 
number of conflicts that will occur in a certain time period, and determine 
the probability of an accident. 


3.1.2 Principal Existing Models 

A number of conflict models have been developed, covering a range of 
complexity. Many of these models are ad hoc and have only been exercised 
in specific studies although they could be generalized for more extensive 
analyses (for example, see [1] for several papers on ad hoc conflict 
detection and resolution concepts). Only major, fairly-well-generalized 
models are discussed below. 

Models can be classified into either “node-link” or “3D” airspace. Node- 
Link models discretize airspace into a number of nodes and links. Aircraft 
move from node to node along the links and conflicts occur when more than 
one aircraft tries to move to a single node. Typically, these conflicts are 
resolved by ‘delaying’ one or more of the aircraft at a node. By necessity, 
node-link models are coarse but may provide rough initial results to identify 
areas where more detailed study is required. Example node-link models are 
ASIM, FLOWSIM, and SIMMOD. Of those, ASIM has been developed 
solely for facilitating the approximate estimation of the frequency of 
conflicts in en route airspace under various air route configurations and air 
traffic control densities; the model offers little else in terms of capabilities. 
FLOWSIM is a low-level -of-detail model concerned primarily with 
estimating flows and delays. SIMMOD is a general-purpose model for 
simulating airport and airspace operations that can also provide preliminary 
counts of the frequency of conflicts en route and in terminal airspace. 

3D models allow aircraft to fly arbitrary three-dimensional routes. In some 
models, aircraft follow specified flight plans exactly; in others, a set of 
dynamics is used to simulate aircraft performance and flight paths may 
deviate from flight plans. Generally, 3D models allow for much more 
realistic conflict detection, and may output metrics such as minimum 
separation or conflict geometry. Additionally, more realistic conflict 
resolution is possible, generally modeled using a simplified rule-base to 
provide avoidance commands. Example 3D models with conflict resolution 
components are ARC2000, BDT, RAMS, and TAAM. ARC2000 was 
designed to evaluate rule-based conflict resolution strategies in a realistic 
environment. BDT is a very basic simulator used solely for conflict 
detection and resolution. Thus, ARC2000 and BDT can be characterized as 
special-purpose models. RAMS, by contrast, is a general-purpose tool for 
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airspace simulation with a conflict detection/resolution feature, among 
others. Similarly, TAAM is a general-purpose model for simulating 
airspace and airport operations. Other 3D models, which do not currently 
include conflict resolution, are NARSIM and TMAC. 


3.1.3 Model Comparisons 


Table 3.1 shows a comparison of the currently-available major conflict 
models. The Trajectory Generation column refers to the requirement that 
aircraft flight plans be prespecified. ASIM has the ability to incorporate 
either predefined flight plans or to generate flight plans based on a statistical 
description of flights between airport pairs. Similarly, RAMS can either 
take predefined flight plans or can generate lateral flight plans based on 
origin and destination airports (the vertical path must still be specified). For 
example, a company (CSSI) and the FAA have recently co-operated on 
developing an extensive set of predefined wind-optimal flight plans for use 
with RAMS. All other models require that flight plans be completely 
prespecified through an input file. 


Table 3.1: Conflict Model Capabilities 


Model 

Trajectory 

Generation 

Trajectory 

Simulation 

Conflict 

Resolution 

Multi-Aircraft 

Conflicts 

ARC2000 

Req’d as input 

3D 

Rule-Based 

Pairwise 

ASIM 

Automatic 

Node-Link 

None 

None 

BDT 

Req’d as input 

3D 

Algorithmic 

Complex 

FLOWS IM 

Req’d as input 

Node-Link 

Delay 

None 

NARSIM 

Req’d as input 

3D 

Human 

Human 

RAMS 

Automatic 

3D 

Rule-Based 

Pairwise 

SIMMOD 

Req’d as input 

Node-Link 

Delay 

None 

TAAM 

Req’d as input 

3D 

Rule-Based 

Pairwise 

TMAC 

Req’d as input 

3D 

None 

None 


The Trajectory Simulation column refers to whether the model uses a Node- 
Link airspace structure or a 3D, non-discretized airspace model. In Node- 
Link models, conflicts are detected only when two aircraft attempt to move 
to the same node. This approach is obviously unable to indicate the conflict 
severity or to provide details on the geometry of the aircraft involved. 3D 
models detect conflicts using criteria that define a conflict (e.g., minimum 
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miss distance or the intersection of cylinders around each aircraft). These 
criteria are generally specified by the user in an input file. 

The Conflict Resolution column describes the method by which conflicts are 
resolved. “Rule-Based” resolution corresponds to the use of a set of rules 
by which appropriate resolution maneuvers are determined and 
implemented. Rule-Based resolution typically uses a single type of 
resolution maneuver (e.g., “jog right and then return to the flight plan”). In 
the case of RAMS, the Spanish Civil Aviation Authority has recently 
connected PUMA (a human/automation model, see next Section) with 
RAMS so that information can also be obtained about human workload in 
conflict resolution. “None” indicates that the model only counts conflicts 
and does not attempt to resolve them. “Algorithmic” resolution describes a 
model that uses more complex algorithms to resolve conflicts. “Delay” 
resolution indicates that the model resolves conflicts by simply delaying one 
aircraft at a node. “Human” indicates that conflicts are resolved in real time 
by a human controller, there is no automated conflict resolution. 

The Multi-Aircraft Conflict column indicates the method by which the model 
resolves simultaneous conflicts between more than two aircraft. “Painvise” 
resolution describes a model that represents these multi-aircraft conflicts as 
several pairwise (one-on-one) conflicts. Each conflicting aircraft pair is 
resolved without regard to a possible global solution. Thus, there may be 
multi-aircraft conflict situations that pairwise resolution is unable to resolve 
successfully. “Complex” resolution capabilities are currently only available 
in BDT and include the ability to incorporate complex conflict resolution 
modules using genetic algorithms or other methods. BDT has been used to 
resolve globally conflicts between many aircraft. 

Table 3.2 outlines the major conflict-related outputs of the models listed in 
Table 3.1. This listing provides an indication of the level of complexity of 
the underlying model and its flexibility for future studies. As mentioned 
earlier, a number of other ad hoc algorithms for conflict resolution have 
been developed (e.g., [2]) but are not included in Tables 3.1 and 3.2 
because they do not constitute formal “models”. These algorithms are 
typically evaluated using randomly generated traffic situations and record 
metrics such as miss distance, number of aircraft involved in conflicts, etc. 
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Table 3.2: Conflict Model Outputs 


Model 

Outputs 

ARC2000 

conflict density, unsolved conflicts, trajectory deviations, 
time/fuel penalties 

ASIM 

conflict counts / locations 

BDT 

conflict count, miss distance, geometry, aircraft state 
(speed, altitude, etc.) 

FLOWSIM 

delay (position & time) 

NARSIM 

conflict detection 

RAMS 

conflict start / end times, trajectories 

SIMMOD 

delay, traffic flow (position & time) 

TAAM 

delay, conflict count & severity, unsolved conflicts 

TM AC 

delay, conflict count (position & time) 


3.1.4 Individual Model Assessment 

The node-link models (ASIM, FLOWSIM, SIMMOD) are generally useful 
to determine approximate traffic density and conflict areas, but are not 
detailed enough for more complex studies such as determining the 
effectiveness of conflict resolution algorithms. Of the node-link models, 
SIMMOD is generally the most flexible and provides the greatest level of 
detail. However, none of the node-link models is particularly well-suited to 
flexible flight environments (e.g., Free Flight). Their use in connection 
with conflict frequency estimation in such environments would probably be 
time-consuming and not cost-effective. 

Of the 3D models, only ARC2000, BDT, RAMS, and TAAM currently 
have the capability to detect and resolve conflicts at varying levels of 
complexity. 

3.1.5 Collective Model Assessment 

The current state of conflict modeling can be summarized as follows. 
Simple trajectory models are typically used based on prespecified flight 
plans or are randomly generated based on desired traffic density. Aircraft 
dynamics are simple and generic (i.e., aircraft fly from waypoint to 
waypoint at a given speed and altitude). Conflicts are detected and counted 
based on simple geometrical criteria, such as miss distance or penetration of 
safety buffers around each aircraft. Conflict resolution is typically done 
through a simple rule-base and is generally not robust enough to ensure that 
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conflicts are resolved. BDT is currently the only model that allows complex 
resolution algorithms to be implemented and evaluated in a modular form. 
Only a few models (BDT, TMAC) include the capability to model trajectory 
uncertainty. 

3.1.6 Recommended Model Toolkit 

To summarize, tools are needed in the three general areas of Trajectory 
Generation, Conflict Detection, and Conflict Resolution. The appropriate 
toolkit of models would make it possible to perform studies that would (i) 
estimate the conflict rate, given a certain region of airspace and air traffic 
management concept and/or (ii) develop resolution strategies to prevent 
collisions once a conflict occurs. 

For traditional, highly-structured flight environments, issue (i) above could 
be addressed by a general-purpose node-link model, such as SEMMOD, or 
by a special purpose one, such as ASIM. However, these node-link models 
are inadequate in more flexible environments, such as Free Flight, and they 
are just as inadequate for addressing conflict resolution strategies, i.e., issue 

(ii). 

It is, therefore, clear that a state-of-the-art “toolkit” to support conflict 
generation, detection and resolution studies should consist of a combination 
of special purpose models, such as ARC2000 and BDT, and a general 
purpose model, either RAMS or TAAM. 

As mentioned in Section 4 below, it is also recommended that conflict 
models be linked in a toolkit with human / automation models, when the 
controller’s ability to effect the conflict detection or resolution strategy is 
uncertain. Potential human / automation models include PUMA and 
MIDAS, both of which can be used to examine the impact of an ATM 
strategy on operator workload. 

3.1.7 Recommendations for Improvement 

The models discussed above generally provide the capability to examine 
susceptibility to conflicts and conflict resolution at a gross level. However, 
no single model currently provides enough flexibility and capability to 
perform a complete, in-depth study of conflict detection and resolution in 
ATM. More detailed design and evaluation of conflict resolution strategies 
will require more detailed tools. In particular, the following 
recommendations are made: 

(a) Improve Trajectory Generation Models: Estimates of the number and types 
of conflicts that will occur under ATM concepts are strongly tied to 
variables such as weather, airport capacity and demand, and flight plan 
generation methods. Although some tools (such as TMAC) address these 
issues, additional work is required to further expand and verify the 
assumptions and flexibility of these models. It is worth noting that some 
airlines currently have sophisticated trajectory generation tools that are used 
during daily flight planning. Efforts to transfer the expertise from airline 
planners to research tools would be valuable. 
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(b) Expand Toolkit of Conflict Detection and Resolution Models: Current 

models have only crude representations of sensors, processing, and human 
performance. Additional development is required to expand the breadth and 
depth with which analysis tools can be used to evaluate conflict situations. 
Some studies may require rapid high level estimates of performance while 
others may require detailed analysis of specific situations. A toolkit should 
be available to allow investigators to select and use a model with the 
appropriate level of detail. This includes developing or enhancing tools to 
examine the following issues: 

(i) Level of detail of aircraft dynamic models 

(ii) Sensor accuracy and update rate 

(iii) Impact of intent information (e.g., knowledge that an aircraft will 
end its descent at a given altitude) 

(iv) Impact of “Rules of the Road” or maneuvering restrictions (e.g., 
aircraft on the right has right of way) 

(v) Differing equipage between aircraft 

(vi) Role of pilot and ground controller in identifying and resolving 
conflicts 

(vii) Human response to and interaction with conflict alert and resolution 
information 

(c) Develop Tools to Examine Multi-Aircraft Conflicts: There is a clear need to 
develop tools to examine the susceptibility of an ATM system to multi- 
aircraft conflicts and to evaluate candidate conflict resolution strategies 
during multi-aircraft conflicts. While tools such as ARC2000, BDT, 
RAMS, and TAAM are able to address this area to a minor extent, additional 
development is required to allow for more complete, flexible studies. This 
will require tools to: 

(i) Identify the likelihood and geometry of multi-aircraft conflicts as 
functions of airspace density, weather, etc. This includes developing 
metrics of dynamic density. 

(ii) Develop and evaluate conflict resolution strategies. Algorithms for 
resolving conflicts must be developed and the methods by which 
resolution options are provided to a human controller need to be 
determined. The ability of a human controller to resolve complex 
conflicts may be the limiting factor in the design of the traffic 
management system. Thus, appropriate roles of human and 
automation elements must be determined. Additionally, the 
robustness of a given conflict resolution approach needs to be 
evaluated. This includes examining whether a given approach is 
effective in resolving conflicts and whether resolution maneuvers 
induce additional conflicts. 

(iii) Determine the effect of conflicts on overall traffic flow. The 
frequency and types of multi-aircraft conflicts will affect the overall 
efficiency of traffic flow. Tools are needed in this area to determine 
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the potential effect that multi- aircraft conflicts will have on the larger 
ATM system. 

(d) Develop Guidelines for Model / Tool Evaluation: Given the growing 
number and diversity of analysis tools, there is an increasing need to have a 
set of guidelines that aid a user in understanding the capabilities and 
limitations of a given tool. The issues that should be considered when 
choosing a tool for a certain task should be clearly outlined to allow users to 
determine which tool is most appropriate. Additionally, when a tool is used 
to evaluate a proposed conflict detection or resolution method, guidelines 
are required to aid the investigator in assuring that all important issues are 
considered in the evaluation. For example, the investigator should be made 
aware that airspace density may affect the performance of a conflict 
detection system. Thus, either a range of airspace densities should be 
considered or the evaluation should include the caveat that the proposed 
system was only tested at a certain density level. 

(e) I .ink Conflict Models with Human / Automation Models: Establishing links 
between conflict detection / resolution and human / automation models 
would be valuable toward gaining a better understanding of constraints 
imposed by factors outside conflict modeling alone. For example, it could 
be determined that a given conflict resolution strategy is too complex or 
results in too high a workload for a controller to perform. Some coordinated 
studies have already been performed, namely using RAMS and the human 
workload model PUMA (see Section on Human/Automation models). 
Additional work is required in this area and could establish links between 
other models (e.g., SIMMOD and MIDAS). 
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3.2 


REVIEWS 


3.2.1 RAMS: Reorganized ATC Mathematical Simulator 
(Last update: 10/96 EMF) 

1. Model Category 

General purpose ATC modeling environment for enroute/ terminal airspace 
and controller workloads. 

2. Summary 

RAMS is a fast-time simulation tool developed by the Eurocontrol 
Experimental Center (EEC) at Bretigny (France) and CACI Incorporated. 
RAMS is a major upgrade of EAM (Eurocontrol Airspace Model), which 
for the past 15 years has been Eurocontrol's principal simulation tool for 
evaluating proposed changes to airspace structure and sector configuration 
in EC member states. RAMS deals with all segments of flights starting from 
take-off till just before landing. However, runway interactions with airborne 
operations may be modeled, such as for parallel or intersecting runways. 

RAMS provides a flexible airspace simulation environment where a broad 
variety of new concepts may be tested at the desired level of detail. Due to 
the flexible design of RAMS, the system is capable of carrying out 
planning, organizational, high-level, or in-depth studies of a wide range of 
ATC concepts. This design includes 4-dimensional flight profiles, conflict 
detection and conflict resolution mechanisms, workload models, modem 
user interfaces and a data preparation environment. 

RAMS offers an integrated simulation study environment, with many 
advanced features to assist the user in the development, simulation and 
analysis of an ATC system. 

Competing models are TAAM, ASIM, and, to a lesser degree, SIMMOD. 

3. Input Requirements 

Airspace description: The format used for sector definition is based on a 
list of comer points, 2D boundaries (a list of connected points), and the 
airspace definition (to add the third dimension and ATC information). 
RAMS has an integrated database facility which allows the extraction of 
data from a number of sources including the Jeppesen database of 
Europe, Eurocontrol or CFMU. If it is required to parse another, 
unsupported format, RAMS offers the possibility for users to define 
BNF style parsing facilities without a requirement to modify the RAMS 
code. FAA users have reported temporary difficulties because of the 
unusual airspace definition format, sometimes leading to overlapping 
sectors when comer points are redundant. 

Rule-based resolution system: RAMS may work with or without 
automatic conflict resolution. It may also run in real- time, and a human 
controller can then interact with the software. When running in 
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automatic mode, each controller in RAMS may be attributed a specific 
set of rules (the basic ATC conflict resolution rulebase contains over 
100 rules) that RAMS will use for automatic conflict resolution. These 
rules may be defined sectorwise to account for local habits and working 
conditions. 

Conflict probes can use a variety of conflict alert zone shapes. The basic 
shapes are rectangles, circles, ellipsoids, diamonds and users are 
required to select one of these only. 

The separation values applied to aircraft are defined by any one of a 
number of sources, including the required controller separation, wake 
turbulence, oceanic flight metering fixes and the relative geometry of the 
flights in a conflict. All these features are optional and may be modified 
by the user. 

- Flight plan description: RAMS offers the capability of simulating the 
entire flight plan in as much detail as desired. It can also generate flight 
plans automatically: Given a cruising altitude, the origin and the 
destination of a flight, RAMS can generate a flight plan with a climb 
path and a descent path based on specific aircraft performance. Aircraft 
performance is currently coded in lookup tables. 

Workload analysis: A virtually unlimited number of tasks may be 
defined for workload analysis purposes. 

- Weather patterns - Special use airspace: Convective weather patterns and 
Special Use Airspace can be accounted for via time- varying forbidden 
zones. 

4. Outputs 

By carrying out comparative analyses between different simulated 

scenarios, the effects of proposed changes can be expressed in terms of: 

1 . Distribution of workload over centers, sectors, and individual control 
positions; 

2. Traffic loads within each sector/center overall and per route, level band, 
point, classified according to cruise, climb and descent; 

3 Penalties imposed upon traffic resulting from imposing ATFM 
measures, flight level changes, en-route/ground delays, and anrival 
holding. 

4. Frequency distribution based on many iterations of a given scenario 
(Monte-Carlo simulations). 

Users of RAMS have mentioned that its post-processing capabilities are 

rather poor. Outputs are reported to consist mainly of large, unprocessed 

output files (trajectories, conflict start and end times). 
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CSSI seems to have developed a graphical tool based on SDAT, an 
interactive airspace building tool, to post-process some of RAMS' outputs. 
The contact name at CSSI is Stephane Mondoloni. 

5. Major Assumptions 
Unknown. 

6. Computational Characteristics 

Hardware Requirements: The system runs on HP9000 series 700 
workstations. There are currently no plans to implement RAMS on any 
other machine. 

Software Requirements: RAMS comprises over 160,000 lines of 
Modsimll. Machines with 256 Mb of RAM or higher and a disk of 4 Gb 
or more are recommended for serious use of the system. MODSIM II is 
a fully object oriented simulation language developed by CACI Products 
Company that generates C code. It runs under UNIX under X-windows 
or its HP-Vue Window equivalent. The source code is not available to 
any users. 

- Execution Characteristics: Typical speeds can range from 3 to 20 times 
real-time, depending on the desired simulation. Very small simulations 
may run up to 100 times real-time. FA A users have reported that it took 
10 hours to run a 1-day, 12,000 flight simulation without conflict 
resolution. 

- Documentation: According to the FAA users, the documentation to users 
is "adequate", and the graphical user interface is "adequate to good". A 
future site for RAMS information, documentation, online user support, 
users group and News/Discussion forum will be defined soon. 

7. Learning Efforts 

RAMS requires relatively modest learning effort. According to the 
developers, two weeks are necessary to get familiar with RAMS. FAA 
users reported 1 month as necessary to really get comfortable. A typical 
initial study may require frequent contacts with Eurocontrol. 

8. Modularity and Flexibility 

RAMS is currently a closed-architecture software system. However, the 
development plans for RAMS include moving towards an open architecture, 
where externally developed modules could bypass some of RAMS' 
functions (e.g. conflict resolution). AENA, the Spanish Aviation Authority, 
has interfaced RAMS with the surface simulation part of SIMMOD and with 
PUMA, the human workload simulator, with relatively modest 
programming effort. 

9. Status 

RAMS official release 2.0 w’as carried out in November 1995. RAMS 2.1 
has been released internally to Eurocontrol and will be available early May 
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1996. These developments include moving towards an open modular 
architecture. 

Current RAMS users include Eurocontrol Experimental Center, FAA/OR 
Washington, AENA Madrid, Transport Canada. Demands for RAMS have 
been received from CENA (France), Irish CAA, NATS (UK), DFS 
Frankfurt and MIT. A first RAMS user's group meeting is planned for June 
1996. 

10. Extent of Model Verification 

RAMS has been tested by the FAA in a study to evaluate the effects of direct 
routing on airspace operations in New England. It has been reported as "the 
best available airspace simulation tool". 

11. Principal Applications 

ATC workload 
Free Routing investigation 
Free Flight investigations 
Airspace capacity, density 

12. Availability 

RAMS is available from Eurocontrol. Currently, RAMS availability needs 
to be negotiated on a case-by-case basis. 

13. Contacts 

Contacts in Europe: 

Mr. Frank Jelinek 

RAMS External Client Support 

Model Development Team (MDV) 

BP 15 

91222 Bretigny sur Orge cedex 
France 

Tel: (1)69 88 73 93 

Fax: (1) 60 85 15.04X 

Email: frank.jelinek@eurocontrol.fr 

RAMS support team 

Email: ramssupport@eurocontrol.fr 

Web: http://www.eurocontrol.fr/~mdv 

Contacts in the United States: 

Mr. Steve Bradford 
FAA 

(202) 358 5234 
sbradford@mail.hq.faa.gov 
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Mr. Stephane Mondoloni 
CSSI 

(202) 488-0003 

Stephane.Mondoloni@mail.hq.faa.gov 

14. Report Sources 

Interviews conducted at FAA on December 18, 1995, with Steve Bradford 
(FAA), Stephane Mondoloni, Willie Weiss and Bill Colligan, all of CSSI, 
and on January 1 1, 1996, at Eurocontrol with Ian Crook. 

15. Summary Evaluation 

RAMS is a new airspace operations simulation tool developed for 
Eurocontrol. While currently it has a closed-architecture, RAMS apparently 
offers enough freedom to investigate many aspects of future concepts such 
as flying direct routes. However, this simulation tool is very recent and 
extensive usage is necessary to fully assess its capabilities. 

3.2.2 ARC2000: Automatic Radar Control for the years beyond 2000 
(Last update: EMF 10/96) 

1. Model Category 

Airspace traffic management and control model assuming advanced aircraft 
flight management systems. 

2. Summary 

ARC2000 is a tool developed at Eurocontrol Experimental Center (EEC) to 
assess the feasibility of automated ground-based separation assurance at a 
target date beyond 2015. The goal of ARC2000 is to demonstrate that 
automated air traffic control can maintain a conflict-free portion of the 
airspace for unlimited periods of time, and under high traffic densities. In 
particular the automatic system should be able to recover from unforeseen 
events and irregular operations. It is based on ideas that emerged from older 
projects such as ASTA (ATM Strategic and Tactical Advisor) which 
explored the advantages that might accrue to ATM from advanced cockpit 
automation. 

The main assumption in ARC2000 is the availability of 4D-FMS and the 
ability for aircraft to fly almost exactly trajectories defined 25 minutes in 
advance. Controllers and sectors are virtually eliminated from the ARC2000 
environment. Conflict resolution clearances are generated automatically on 
the ground and sent to aircraft using data- link. Consequently, ARC2000 
does not provide Human Machine Interface (HMI) for controllers to 
manually exercise Air Traffic Control, even though the simulation is 
displayed on a high-resolution 29" screen used in ATC. 

A significant by-product that emerged from the ARC2000 project is HIPS 
(Highly Interactive Problem Solver), also developed by the EEC. HIPS is 
an interactive conflict resolution aid which also presumes 4D-FMS 
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capabilities that can be used by both controllers and pilots in a decentralized 
conflict resolution scheme. This tool will be tested in the forthcoming 
European experiments PHARE Demos 1 and 3. 

The ARC2000 assumes that control instructions are prepared automatically 
and delivered by the system to aircraft via data-link. Typically, the model 
assumes direct flights from zone entry to exit, although it can accommodate 
non-direct routings. Navigation is based on pseudo flight plans where 
constraints are specified in lieu of a formal flight plan (RNAV traffic). In a 
typical scenario most of the traffic is overflying while a significant 
proportion of flights depart from or enter pseudo-terminal areas with 
metering down to predefined levels over specified points. 

The model can simulate unanticipated events or disturbances including 
activation/deactivation of Temporary Reserved Areas (TRAs) and flight path 
deviations using either the Multi-Aircraft Cockpit Simulator (MCS) or 
predefined data for specific aircraft, Possible degradation of aircraft 
capability or air to gound data exchange are not accounted for in ARC2000, 
however the decision -aid derivative, HIPS can account for degraded 
aircraft capabilities. 

3. Input Requirements 

To run an ARC2000 simulation the following input files are needed: 

1 . The simulated airspace which consists of two main elements: 

a. A description of the portion of the airspace where ARC2000 
operates. This area should be large enough to provide sufficiently 
long flying times (greater than one hour) permitting a strategic 
approach to air traffic control. Interfaces with adjacent airspace 
should also be appropriately described. The area currently simulated 
is a polygon covering the northern Spain and Portugal, the western 
part of France and the southern part of Great Britain and Ireland.; 

b. Traffic samples: ARC2000 uses recorded flight tracks as the basic 
traffic input. To model higher traffic densities flight departure times 
are concentrated and traffic is cloned. Two 2-hour long traffic 
scenarios have been generated, one with 508 aircraft and the other 
with 750. 

2 . The maneuver priorities and associated parameters. 

3 . The sequencing points and associated parameters. Note that sequencing 
can only be done at waypoints or arrival/ departure routes. 

4. Deviation thresholds: The ARC2000 system monitors the aircraft 
positions, in order to verify that aircraft fly their predicted trajectories, 
and, if not, to take appropriate actions. 

5. tLateral separations between aircraft: The separation standards are 
aircraft- and speed- dependent and have been adapted to take into 
account the real-life imperfections of 4D-FMS. This may result in 
separation standards that are higher than the ones currently in use. 
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6. Vertical separations. 

7 . The time horizon for conflict resolution. 

4. Outputs 

During a ARC2000 simulation each action is recorded, so it is possible to 
obtain statistical results about: 

• the aircraft density in the airspace; 

• the conflict density in the airspace; 

• trajectory deviations; 

• unresolved conflicts; 

• extra route distances; 

• other parameters 

5. Major Assumptions 

Each aircraft is assumed to be equipped with 4D FMS. Datalinks have 
infinite bandwidth and computational power is infinite. Conflict resolution 
is automatic. 

6. Computational Characteristics 

Hardware Requirements: The system runs on a HP 9000/755, but in 
principle, it could run on any machine in the 700 series, since PA- 
RISC 1.1 machine code was generated. The display position 
requires two screens equipped with PEX 5.0 servers. The 
supervision position requires one screen equipped with an X 1 1 
release 5 server. The screens used are each 29 inches wide. The 
display position uses Xlib and PEXlib software while the 
supervision position uses X- toolkit and Motif library software 

Software Requirements: The ARC2000 software was written in ADA and 
ANSI-C and is divided into component sub-systems. There are 28 
identifiable sub- systems spread over 1041 files. There are 301,093 
lines of code: 

• 4,465 lines of C ; 

• 167,004 lines of ADA; 

• 66,194 lines of comment; 

• 63,430 blank lines. 

Execution Characteristics: A typical simulation with 506 aircraft and 3 hours 
of traffic lasts 3 hours. 

Documentation: The following documents are available from EEC (at 
Bretigny France): 
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1 . “ARC2000 TECHNICAL REPORT” Task AS06 EEC Report: 274 
(December 1994). Aside from ARC200 specific information, this 
document contains a detailed description of BADA (basic aircraft 
performance database) in use in many of the European ATC fast-time 
and real-time simulation facilities, such as NARSIM in the Netherlands. 

2. “ARC2000 USER GUIDE’ (July 1995) 

3. “ARC2000 SOFTWARE SPECIFICATION 2.0” 1992 

4. “ARC2000 PARAMETERS” Task AS 10 Internal EEC note: 
3/B2. 1/1995 

5 . A flyer describing the main features of ARC2000 

6. An overview of ARC2000 Version 3 from the operational point of view, 
EEC Report: 286 (1.15.1996) 

7. Learning Effort 

The system is well documented. One beginning engineer at Eurocontrol 
needed 2 weeks to run a first simulation. 

8. Modularity and Flexibility 

ARC2000 has been coded in mostly ADA, which allowed the programmers 
to make it very modular. For example, several subroutines of ARC2000 
were subsequently integrated in HIPS with no reported problems. 

9. Status 

ARC2000 is now frozen and HIPS is being tested in the real-time 
simulations, field experiments PHARE Demo 1 and 3 and in several 
European research Laboratories. Three people work on ARC2000 at EEC. 
Several more people work on HIPS (at EEC Bretigny, DRA (UK), NLR 
(The Netherlands)). 

10. Extent of Model Verification 

Some of the assumptions (4D planning) within ARC2000 will be evaluated 
through the use of HIPS in the PHARE project (PHARE Demo 1 and 
PHARE Demo 3). Results are expected by 1998. ARC2000 seems not to 
have been used outside EEC. 

11. Principal Applications 

Airspace Capacity Limits. Investigation of automated conflict avoidance up 
to 25 minutes in advance. Modelling of strategic conflict resolution for 
direct en-route airspace. 

12. Availability 

ARC2000 may be available at no cost under EUROCONTROL (FAA MOC 
annex 5). 
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13. Contacts and information for model evaluation 


Xavier Fron (Division head) 

Tel.: Oil 33 1 69 88 75 30 
email: fron.xavier@eurocontrol.fr 

Jean-Pierre Nicolaon 
Tel.: Oil 33 1 69 88 76 71 
email : nic@eurocontrol.fr 

FrEdErique Ayache 
email: aya@eurocontrol.fr 

14. Summary Evaluation 

ARC2000 is specifically targeted to the study of ground-based, automated 
conflict avoidance based on 4D-FMS availability. The goal is to 
demonstrate improvements in capacity that are possible using this method. 
Resolution success rate is still too low to consider operational 
implementation in an automated system. However, the strategic conflict 
resolution features of ARC2000 seem to generate very cost efficient 
solutions (less than 1 % time and fuel penalty) under high traffic load. Those 
ARC2000 features could be added to RAMS to model a two-tier ATC with 
strategic and tactical conflict resolution. 

3.2.3 BDT: Banc De Test 

(Last Update: NP, EF 10/96) 

1. Primary Model Category 

Simulation tool which generates aircraft trajectories to test automated 
conflict resolution algorithms. 

2. Summary 

The Banc de (Test tool (BDT) was developed at Centre d'Etudes de la 
Navigation AErienne (CENA) as a support tool in the AGACER project 
(Algorithmes GEnEtiques AppliquEs au ContrUle En Route). The main 
process of BDT uses aircraft flight plans and simplified dynamics to 
generate trajectories in a given airspace. It can be used alone to detect and 
count conflicts (i.e. horizontal or vertical separation violations), or used as a 
testbench for an independent conflict resolution module. 

Competing models include RAMS, TAAM, and ASIM. 

3. Input Requirements 

• Location of navigation beacons in the airspace; 

• Basic aircraft performance data for each aircraft type; 
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• Flight plans containing a list of navaids and the requested flight level. 

4. Outputs 

The standard outputs of the model are: 

• Departure time, arrival time and delay for each flight. 

• Number of airplanes in the air and their altitudes, at 5 minutes intervals. 

• For each conflict: the miss distance, the aircraft involved and their 
positions, speeds, altitudes, ...just before and just after the separation 
violation. 

Additional code has been written to extract higher level conflict information 
and statistics from these standard outputs, but it is not well documented and 
it is not easy to use. 

5. Major Assumptions 

Aircraft trajectories are simplified: 

Aircraft climb directly to the cruise flight level at a constant speed and rate of 
climb; 

Airspeed and altitude are constant during the cruise segment; 

Aircraft descend directly to their destination at a constant speed and rate of 
descent; terminal areas and airport capacity are not modeled. 

Trajectory variations are modeled as randomness in ground speed and 
climb/descent rates. 

Additional assumptions are usually made in the conflict resolution modules. 

6. Computational Characteristics 

The source code was written in C and was available for the evaluation. It is 
well structured and well documented. 

1. Hardware requirements: 

• platform: the evaluation was done on a Sun Sparc 5. 

• operating System: Unix. 

• memory: 32 Mb of RAM, 10 Mb of hard drive. 

2. Software requirements: GNU C compiler. 
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3. Documentation: No formal user's guide is available. This is mostly a 
research tool. A document describing the structure and functions of the 
model was used for the evaluation. However this document does not 
contain complete information on configuration files and input/output 
formats. 

4. User interface: Very limited. The program runs as a batch file. 

5. Typical run time: A few minutes without conflict resolution. 
Considerably more with conflict resolution, depending on the algorithm. 
Typical algorithms include Genetic Algorithms. 

7. Startup Effort 

The program is easy to run in less than a week. 

8. Modularity and Flexibility 

The source code is modular and well organized. This is an open-architecture 
software system. Different conflict resolution schemes can be selected 
without modifying the source code. The source code was made available to 
MIT. 

9. Status 

The model is continually evolving. It is currently used by French civil 
aviation research groups to test several automated conflict resolution 
schemes (including optimization by Genetic Algorithms). 

10. Extent of Model Validation 

Unknown. 

11. Principal Applications 

The principal application of this model is currently the evaluation of tactical 
conflict resolution algorithms. 

12. Availability 

Upon request to Jean-Marc Alliot, CENA, FRANCE. 

13. Information for Model Evaluation 

Source code, simulation runs v and discussions with Jean-Marc Alliot, Centr 
d'...tudes de la Navigation AErienne. 

14. Contact Points 

Jean-Marc Alliot 

Centre d'etudes de la Navigation Aerienne 
7 avenue Edouard Belin 
31055 TOULOUSE CEDEX 
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Phone:011-3362-17-4054 
Email: alliot@pc-allt.eis.enac.dgac.fr 

15. Summary Evaluation 

BDT is a modular program which allows testing of new automated conflict 
resolution schemes at the tactical level. It is not a system-wide model, and it 
could not be readily used to validate Air Traffic Control concepts (e.g. Free 
Flight). In particular, it does not presently take into account Air Traffic 
Flow Management, terminal areas, airport capacities and weather. The 
developers plan to use RAMS to test their conflict resolution tools in a more 
realistic environment. 


3.2.4 NARSIM 

(NLR ATC Research Simulator, NLR: Nationaal Lucht-en 

Ruimtevaardaboratorium, National Aerospace Laboratory, Netherlands) 

(Last Update 6/18/96, KK) 

1. Primary Model Category 

Real-time Air Traffic Control simulation with humans and real ATC systems 
in the loop. 

2. Summary 

NARSIM is NLR's in-house Air Traffic Management (ATM) and Human- 
Machine Interface (HMI) research simulator facility. It simulates aircraft, 
radar, weather and automated air traffic control. NARSIM has been used for 
research and development of advanced automated tools and the development 
integration of ground and air based systems. The advanced automated tools 
aid in prediction of aircraft trajectories, conflicts, and excessive deviations 
from the planned routes. Research in Human-Machine Interfaces is intended 
to aid in air traffic controllers' workload reduction. 

NARSIM is also being used in international research projects such as 
PHARE for 4D ATM concepts which is the research part of the European 
Air Traffic Control Harmonisation and Integration Program (EATCHIP) 
conducted by Eurocontrol for the development of next decade's European 
Air Traffic Management System (EATMS). 

3. Inputs 

Complete simulation of an air traffic control system would typically require 
comprehensive data on the environment and agents. NARSIM premodels 
the basic ATC system so modifications or new concepts can be 
incrementally added for evaluation. Playback of real live or recorded traffic 
can be used for realism. Additionally computer generated traffic with 
pseudopilot (human blipdrivers on computer consoles) assistance may be 
utilized. 
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4. Outputs 

Generally NARSIM operates in near-real time and recordings of the entire 
modeled and real state can be made for post analysis of events and agent or 
system performance. 

5. Major Assumptions and Limitations 

The basic ATM system modeled is that of the Netherlands and neighboring 
EU countries (to a limited scale). It is possible to adapt the system to other 
environments. The system operates in real time and principally provides a 
substitute for experimentation in real ATC systems. The realism of the 
simulation is intimately tied up with the ability to generate realistic 
conditions and for that purpose real live or recorded data and pseudopilots 
(human blipdrivers) flying computer generated traffic are used by 
NARSIM. 

A fast time mode without humans in the loop is also available for evaluation 
of conflict alerting and detection tools as an example. This mode can be up 
to 50 times faster than real-time depending on the complexity of the 
simulation and computer performance. 

6. Computational Characteristics 

NARSIM runs principally on an HP 9000 model 887, running HP-UX with 
approximately 110 MIPS (45MFLOPS), 128MB memory and about 4GB 
disk space for simulations with moderately heavy algorithmic load. For 
blipdrivers and software development purposes 9 X-terminals are connected 
to the main NARSIM computer. 

The display computers are HP 9000 models 300 and 700. The display 
controllers for the ATC Controller positions are two Metheus Omega 3720 
controllers (being replaced by new Metheus and Barco controllers, 
compatible with X-Windows) connected to two 20"x20" Sony raster 
monitors. The main NARSIM computer links all NARSIM computers to the 
Internet through the NLR wide network. 

7. Modularity and Flexibility 

NARSIM has a modular structure, implemented using a custom CORBA- 
like Client/Server middleware. Modules in different languages (typically C, 
Ada and Fortran) can possibly run on different hosts without any 
knowledge of underlying distributed system. The middleware makes it 
possible to add and remove modules during a simulation, and also allows 
for connecting NARSIM to other ATC simulators or flight simulators. 
Several international distributed simulations have been held, connecting 
NARSIM to a NASA flight simulator, the NLR flight simulator and ATC 
simulators from Eurocontrol (France) and DLR (Germany). 

8. Status 

NARSIM is a relatively mature simulation system and has been used in a 
variety of ATM studies. 


78 


9. Extent of Model Verification 


NARSIM has been used extensively and as a large proportion of the 
simulation is essentially real, model verification is perhaps not an issue. 

10. Principal Applications 

Evaluation of new ATM concepts and procedures in realistic partially 
simulated ATC environment. 

11. Availability 

NARSIM is available at the NLR, Netherlands. 

12. Information for Model Evaluation 

Michiels, R., et. al, NARSIM Homepage, NLR, July 21st, 1994, 

NLR NARSIM Brochure 

13. Summary Evaluation 

NARSIM is NLR's ATM research simulator and supports ATM research 
within NLR. This includes evaluating new operational procedures, 
building, testing and evaluating new controller assistance tools and 
prototyping man-machine interfaces. NARSIM includes the following tools: 

The Trajectory Predictor(TP) tool which, based on an aircraft's flightplan, 
flight progress, current position and meteorological data, computes and 
stores the expected 4D-trajectory. 

The ACOD (Area Conflict Detection) tool which supports the air traffic 
controller by detecting conflicts between aircraft using both planning data 
and actual radar data.and can therefore be considered as a medium term 
planning conflict detection tool. 

The STCA (Short Term Conflict Alert) tool supports the executive air traffic 
controller by detecting future separation infringements between aircraft from 
data supplied by the radar data processing system, and can therefore be 
considered as a safety net tool for short term periods. 

The FPM (Flight Position Monitor) supports the air traffic controller by 
monitoring flight progress, detecting deviations from the planned route and 
possibly suggesting corrective actions. 

NARSIM is linked to the Netherlands ATC system (Schiphol) providing 
live radar data in ASTERIX format over a 9600 baud line. To evaluate new 
FMS concepts, this link is used to transmit information such as tracked 
radar data. 

For evaluation of controller assistance tools on NARSIM there is a facility 
to play back recorded traffic. These recordings include radar, flightplan and 
meteo data as available in the current SARP system. NARSIM can also play 
back traffic recordings from the Maastricht Eurocontrol centre. The 
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collection of recorded live-traffic (approximately 30 hours) includes average 
and most special circumstances to appear in every-day air traffic control. 
Special recordings include high traffic loads due to diverted traffic from 
surrounding airports and bad weather conditions. To create extreme 
conditions several recordings can be mixed to increase the amount of traffic. 

The simulation scenarios for the air system are based on a set of initial 
flight-plans. The scenario generator has parameters to select certain types of 
flight and the number of flights per minute (continuous or with randomized 
intervals) for each type. The output of the scenario generator is editable, and 
final manual adjustments are made to get things 'just right’. 

NARSIM presently simulates almost all important entities involved in 
current air traffic control including the air traffic system, parametrized radar 
models, several ATM tools and display software. From a practical point of 
view this means that NARSIM can simulate most aspects of a real 
contemporary air traffic control system with some human help (such as the 
blipdrivers). 

3.2.5 ASIM: Airspace SIMulation 

(Last Update: 10/96 EMF) 

1. Model Category 

Airspace complexity evaluation tool. 

2. Summary 

ASIM is a tool developed in UK at the Defence Research Agency (DRA) for 
the Civil Aviation Authority / National Air Traffic Services (CAA/NATS). It 
was designed specifically to study the impact of new route structures on the 
United Kingdom airspace operations. It has been used to evaluate the 
complexity of new airspace models (new route structures) for the period 
2015+. At the current stage of its development, ASIM does not fully 
replicate Terminal Area operations, and operations under 10,000ft are not 
simulated. ASIM does not simulate traffic management functions in detail. 

Competing models include TAAM, SIMMOD, RAMS. 

3. Input Requirements 

The ASIM input interface has been designed so as to be compatible with 
most standard databases (e.g. Jeppesen). The following are required as 
inputs: 

- Specific routing node-link structure linking city pairs (similar to 
SIMMOD) 

Sector definitions 

- Aircraft performance characteristics and preferred altitude bounds 
Flight plans 
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Statistical information about the number and frequency of flights 
between city pairs 

Traffic is generated probabilistically from the statistical information The 
aircraft are simply flown from origin to destination. Right levels are 
assigned randomly from a distribution based upon the aircraft type. Aircraft 
may climb or descend either according to specified climb schedules or 
follow ATC rules. While flight plans are pre-defined, actual flight times 
may be modeled by injecting randomness. No specific delays are modeled 
within ASIM. 

4. Outputs 

The main output of ASIM is a detailed report of close encounters between 
aircraft. 

5. Major Assumptions 

ASIM assumes fixed route structure for the airspace. There is no included 
weather model and no attempt is made to model controller actions. It is 
assumed that by introducing random variables in departure times and aircraft 
altitudes, a representative sample of air traffic is generated. 

6. Computational Characteristics 

The current implementation of ASIM is on a DEC Alpha workstation. ASIM 
has been programed in MODSIM, a high-level programming language that 
generates C++ and C routines. 

7. Learning Effort 

It was reported that two people with standard training in ATC can become 
familiar with ASIM in less than a month. The documentation is reported to 
be very deficient by the developers themselves . 

8. Modularity and Flexibility 

According to CAA/NATS officials, ASIM has been developed for the 
purposes of the United Kingdom. However, the model and its underlying 
language are object oriented, and it should be easily adaptable to other 
needs. 

9. Status 

ASIM has been under development for 5 years. Further development 
appears necessary. According to the developers, ASIM should be 
considered a research tool. However, they also consider the basic model 
engine to be fully operational and properly validated. The post processing 
capabilities have been markedly enhanced over the last six months. 

10. Extent of Model Verification 

Unknown. 
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11. Principal Application 

ASIM was used within the Model Use and Fast Time Simulations 
(MUFTIS) project to evaluate the impact of European Advanced Traffic 
Flow Management on UK flights. ASIM has also been used in a number of 
other studies, including the European NOAA work program. 

ASIM was also used to investigate new, simpler route structures in the 
vicinity of London. New route structures included great circles. It was 
found that great circles would reduce the number of conflicts, but would 
also increase the number of crossing points and would change the closest 
point of approach distribution. 

12. Availability 

The software belongs to CAA/NATS and can be made available on a case- 
by-case basis. 

13. Information for Model Evaluation 

Interview with Graham Stamp (CAA/NATS) on January 15, 1996, with 
Rob Whitaker (CAA/DRA) on February 13, 1996, and with Philippe 
Kerlirzin on January 10, 1996. 

14. Summary Evaluation 

ASIM is an enroute simulation model tailored for the needs of the United 
Kingdom. Its main purpose is to evaluate the complexity of airspace under 
current and future route structures, including great circles, by counting the 
number of close encounters. ASIM is a research tool that may be made 
available to NASA following formal agreements. 


3.2.6 RATSG: Robust Air Traffic Situation Generator 

(Last update: 5/8/96 JKK) 

1. Primary Model Category 

Tool to create scripted 4D flight paths of pseudo aircraft. 

2. Summary 

The Robust Air Traffic Situation Generator (RATSG) is part of the MIT 
Aeronautical Systems Laboratory's part-task simulation facility. RATSG 
allows the user to design 4D flight plans (position and time) for a number of 
pseudo aircraft for use in simulation studies. Waypoints can be defined 
relative to fixed earth coordinates or relative to a subject aircraft. The pseudo 
aircraft can automatically change speed, altitude, or heading in order to 
assure that a desired air traffic situation occurs regardless of the actions of a 
human pilot. Although currently used in real-time, human-in-the-loop 
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simulation studies, the tool could be used in fast-time traffic simulations as 
well. 

3. Input Requirements 

A Graphical User Interface is used to develop scenarios and flight plans. 
The user can specify the number and type of aircraft, aircraft call sign, 
transponder status, and whether the aircraft has TCAS. Additionally, 
aircraft initial states (position, altitude, heading, speed) and the 4D 
waypoints are defined either through a text input or graphically. Voice 
messages can be recorded and scripted to play at predetermined times to 
simulate VHF communications. 

4. Outputs 

When running, RATSG outputs pseudo aircraft state data in either real time 
or in fast time. 

5. Major Assumptions 

The aircraft use simple point-mass dynamics. 

6. Computational Characteristics 

Code exists (written in C and GL) for Silicon Graphics Indigo 
workstations. Typical run time in fast mode is 3 minutes for a 30 minute 
flight. 

7. Modularity and Flexibility 

The code is somew'hat modular and has been exported to NASA Ames for 
use in developing traffic encounter scenarios. 

8. Status 

The model is still being used but is not under further development at this 
time. 

9. Extent of Model Verification 

The aircraft model uses simple performance numbers as parameters (e.g., 
best rate of climb, gross weight, roll rate). The values of these parameters 
are based on published aircraft performance data but have not been 
otherwise validated. 

10. Principal Applications 

Development of traffic encounter situations for human-in-the-loop 
simulations. 

11. Availability 

Available through MIT. Contact: Prof. John Hansman, (617)-253-2271, 
ijhans@mit.edu 
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12. Information for Model Evaluation 

Johnson, E. N. and R. J. Hansman, "Multi-Agent Flight Simulation with 
Robust Situation Generation", MIT Aeronautical Systems Laboratory 
Report ASL-95-2, January, 1995. 

13. Summary Evaluation 

The Robust Air Traffic Situation Generator has been implemented on a 
graphical workstation that communicates with the MIT-ASL Advanced 
Cockpit Simulator, allowing specific traffic situations to be designed and 
used in experiments. Traffic encounters are scripted by the experimenter 
using 4D waypoints (position and time). These waypoints can be located 
relative to fixed earth coordinates or placed relative to the subject aircraft so 
that potential collision events can be simulated. VHF communications can 
be simulated by scripting pre-recorded voice for playback during simulation 
runs. During a simulation, the pseudo aircraft are automatically controlled 
through adaptive 4D waypoints to ensure that the traffic situation unfolds as 
desired even if the subject performs unexpected maneuvers. In addition, 
because the simulation is already built around 4D waypoints, a framework 
is already in place to examine advanced 4D traffic control issues with 
multiple aircraft. 

Traffic can be simulated in real time or in a fast mode. A Graphical User 
Interface is used to design the traffic scenarios. 


3.2.7 TOPAZ: Traffic Organization and Perturbation AnalyZer 
(Last Update: 11/1996, KK) 

1. Primary model category 

Safety analysis of (new) operational ATM concepts. 

2. Summary 

TOPAZ (Traffic Organization and Perturbation AnalyZer) is a tool designed 
to evaluate the safety/capacity for (new) operational ATM concepts for 
single or multiple flight phases. TOPAZ consists of a suite of analytical 
model based software modules, the main of which are: 

• High level Petri net based simulation environment, to evaluate 
frequencies of non-nominal event sequences. The main numerical 
packages are: 

• Data base of high level Petri net modules for human, 
environment and systems in ATM 

• Data base of ATM related hazard types, frequencies and 
probability densities 
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• User interface for the modular development of an application 
dedicated high level Petri net 

• User interface for the execution of Monte Carlo simulations 


• Various mathematical models to evaluate fatal ATM related^ accidents 
(collision between aircraft or uncontrolled flight into terrain due to 
crossing a wake vortex of a preceding aircraft). There are numerical 
packages for the following evaluation types: 

• Numerical evaluation of probability density functions of aircraft 
evolution with time 

• Fitting Gaussian mixtures to empirical, Monte Carlo or numerical 
distributions 

• Evaluating a generalised version of the Reich collision risk model. 

• Evaluating a probabilistic risk model of crossing the wake vortex of a 
preceding aircraft (this package is under development at NLR’s 
Informatics division) 

The execution of a safety/capacity evaluation exercise consists of three 

corresponding steps: 

• Assess the frequency of safety-critical non-nominal event sequences 
through running Monte Carlo simulations with the High level Petri net 
simulator. 

• Evaluate the probability of fatal ATM related accidents (collisions 
between aircraft, or collision into terrain due to crossing a wake vortex 
of a preceding aircraft), through a subsequent use of the various 
packages. 

• Through a spreadsheet, combine the results obtained into relevant ATM 
safety measures (fatal accident risks, economic risk, individual risk and 
societal risk). 

3. Inputs required 

In order to execute an operationally truly relevant safety/capacity evaluation 

of a given (new) operational ATM concept, a significant amount of input 

material has to be collected: 

• Description of the operational ATM concept to be evaluated. This might 
be done up to the level of human controller tasks (air and ground), air 
traffic procedures and technical ATM/CNS systems. Starting from a less 
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detailed description is possible, however, the safety evaluation results 
will be less precise (when comparing conceptual designs this even may 
be an advantage). 

• Statistical characterisation of the air traffic scenarios to be evaluated; i.e. 
traffic flow(s), aircraft types, etc. 

• Identification of all relevant hazards, including a qualitative evaluation of 
their effects. This is accomplished through executing a preliminary 
hazard analysis which pays proper attention to all possible sources of 
non-nominal events (human, procedures and technical systems). 

• Develop a high level Petri net model for the operational concept to be 
evaluated. This high level Petri net model should be of sufficient detail 
to represent all event sequences which may play a critical influence on 
the safety/capacity assessment. 

• Identification of parameters or parameter ranges for all elements which 
may have a critical influence on the safety/capacity assessment. This is 
accomplished through collecting statistical data from appropriate data 
bases, and through assessing the allowable ranges of the design 
parameters. 

4. Outputs 

With the help of TOPAZ it is in principle possible to evaluate the safety 
characteristics of an arbitrary (new) operational ATM concept considered, 
due to safety critical non-nominal event sequences. The outputs provided 
consist of frequencies for the occurrence of non-nominal event sequences, 
conditional probabilities of collision (or hull loss) for different types of non- 
nominal event sequences. The practical interpretation of these figures is 
supported by a tree- wise representation, with at the top an overall risk 
measure. If desired, TOPAZ executes safety assessments as a function of 
scenario parameters, e.g. traffic flow. 

5. Major Assumptions and Limitations 

In order to keep things computationally manageable, the level of detail 
which can be handled for each ATM entity is limited. As such the nominal 
models used within TOPAZ are less detailed than those commonly used in 
fast-time air traffic simulation environments (e.g. TAAM). In return, 
however, TOPAZ enables a probabilistic incorporation of rare non-nominal 
event sequences within the analysis. Another limitation is that for every 
instantiation of an operational ATM concept, TOPAZ will often need an 
appropriate adaptation of already available high level Petri net modules. For 
such adaptation a high level of expertise is required from multiple domains 
(stochastic modelling, human factors, air traffic expertise). 

6. Computational Characteristics 
Platform: PC 


86 


7. Modularity and Flexibility 

TOPAZ is a highly modular and flexible system. 

8. Status 

TOPAZ is under continual development for application to advanced 
operational ATM concepts. 

Halfway 1996, TOPAZ has reached a certain level of maturity for the safety 
assessment of Dependent Converging Instrument Approaches (DCIA) with 
help of MITRE's Converging Runway Display Aid (CRD A). 

9. Extent of Model Verification 

The software implementations of the high level Petri net and the Generalised 
Reich collision risk models have been verified for correctness, with 
extensive use of the mathematical basis of those models. Beyond this level, 
the results obtained have been discussed with experts. In the latter case it 
rather would be better to speak about corroboration. 

10. Principal Applications 

• DCIA/CRDA safety assessment for Schiphol airport (Amsterdam) 

• Analysis of advanced ATM concepts in Europe 

• Analysis of Free Flight concept 

11. Availability 

TOPAZ is available through the 

NLR, National Aerospace Laboratory 
POBox 90502, 1006 BM 
Amsterdam Netherlands 

Contact: 

Henk Blom 
+31 20 511 3544 
blom@nlr.nl 

12. Information for Model Evaluation 

Information from developers. 

I. G.J. Bakker and H.A.P. Blom, Air traffic collision risk modelling, 
Proc. 32nd IEEE Conf. on Decision and Control, December 1993, pp. 
1464-1469 (NLR report TP 93292 U). 


87 




II. G.J. Bakker, Traffic Organization & Perturbation AnalyZer (TOPAZ), 
NLR report TR 94040 L, 1994. 

III. Blom and G.J. Bakker, A macroscopic assessment of the target safety 
gain for different en-route airspace structures within SUATMS, NLR 
report CR 93364 L, 1993. 

IV. Everdij, M.B. Klompstra, H.A.P. Blom and O.N. Fota, Final report on 
Safety model, Part I: Evaluation of hazard analysis techniques for 
application to en- route ATM, NLR report TR 96196 L, December 
1995. 

V. Everdij, M.B. Klompstra and H.A.P. Blom, Final report on Safety 
model, Part II: Development of mathematical techniques for ATM safety 
analysis, NLR report TR 96197 L, March 1996. 

VI. Everdij, G.J. Bakker and H.A.P. Blom, Application of Collision Risk 
Tree Analysis to DCIA/CRDA through support from TOPAZ, NLR 
contract report, 1996. 

VII. Everdij, H.A.P. Blom and M.B. Klompstra, Extending Petri nets 
for Air Traffic Management safety purposes. Paper to be published in 
1997. 

13. Summary Evaluation 

TOPAZ enables the evaluation of safety for a given (new) operational ATM 
concept during a particular or during various flight phases. In order to 
execute such evaluation, TOPAZ consists of a suite of analytical model 
based software modules, the main of which are a high level Petri net based 
simulation environment and mathematical packages to evaluate ATM related 
incidents. The nominal events modelled within TOPAZ may be less detailed 
then those commonly used in fast-time air traffic simulation environments 
(e.g. TAAM). In return, however, TOPAZ enables a probabilistic 
incorporation of rare non-nominal event sequences. 

TOPAZ is an analysis tool for the numerical evaluation of collision risk 
using the generalized Reich collision risk model as described in the paper 
(Bakker & Blom, 1993). 

TOPAZ allows safety and capacity assessment for evaluation of new route 
structures in combination with new ATM concepts. Collisions of all types 
are considered: head-flank, head-head, head-tail, flank-flank and top- 
bottom. 

TOPAZ simulates the probability density functions along the 3D route 
structure rather than the individual aircraft trajectories and evaluates the 
collision risk between aircraft as a function of traffic flow. Maximum 
capacity is determined as that where the risk coincides with a preselected 
target value. 
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4.0 HUMAN / AUTOMATION MODELS 


4.1 REVIEW OF HUMAN / AUTOMATION MODELS 

4.1.1 Definition 

Human/automation models are used to investigate issues that place 
requirements on or result from the interaction between humans and 
automation. Additionally, human performance is often a critical factor in the 
safety of a system and must be considered during risk analysis. The human 
can be a pilot or a ground controller and the automation may affect an 
aircraft, air traffic control station, or the entire air traffic system. Because 
humans are extremely complex components of the larger system, these 
models typically attempt to capture the most essential aspects of human 
performance, but obviously cannot fully describe it. 


4. 1.2 Principal Existing Models 

Human/automation modeling capabilities range from human-in-the-loop, 
real-time simulation environments to complex computer-based, fast-time 
mathematical models and simulations of human behavior (Figure 1). 
Human-in-the-loop simulation studies are typically used to determine 
human-centered requirements (e.g., the minimum information set needed by 
a pilot to determine an appropriate course of action) as well as human- 
induced constraints (e.g., the number of aircraft that can be handled 
simultaneously by the control team of an enroute sector). Typically, these 
studies can be quite detailed, but also require a large investment of time, 
resources, and equipment; thus only a limited set of conditions can generally 
be examined. Additionally, human-in-the-loop simulation studies are often 
limited to examining only incremental system evolution: revolutionary 

concepts can be difficult to incorporate when using hardware designed for 
(and humans trained for) existing systems and their immediate extensions. 

Results from human-in-the-loop simulation studies can be used to develop 
mathematical models that can, in turn, be used to examine a wider range of 
conditions. These models incorporate a representation of the salient human 
parameters (e.g., reaction time) that may impact the overall system under 
study. System-level requirements and constraints (e.g., required sensor 
accuracy) can then be determined in fast-time, using numerical simulation, 
over a wide range of conditions. Results and issues raised from the fast- 
time simulations are then used to better focus future human-in-the-loop 
studies. This, in turn, leads to an improved understanding of issues related 
to humans and automation in ATM and thus, eventually, to better 
mathematical models. In this way, human-in-the-loop simulations and 
mathematical model studies complement one another. 
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Figure 1: Human Simulation and Mathematical Models 


Mathematical models of humans can be classified as macroscopic or 
microscopic. Macroscopic models can be used in stand-alone form to 
provide approximate estimates of human performance for a single condition 
or they can be incorporated into fast-time simulations for representing 
overall human performance. Generally, macroscopic models are useful for 
statistical studies intended to explore the performance of a system that has 
many human operators. Macroscopic models are less useful for predicting 
the performance of specific individuals. Example macroscopic models 
include McRuer’s crossover model for manual control tasks or utility theory 
models for decision making tasks [1]. Numerous ad hoc macroscopic 
models exist, such as simple models of expected pilot reaction time (latency) 
to a warning signal. Additionally, techniques, such as neural networks or 
fuzzy logic, can be used to provide a relatively simple representation of a 
complex decision making process. 

Microscopic models are detailed representations of humans typically used in 
discrete-time simulations of a human operating within a larger system, such 
as an aircraft or an air traffic management system. Typically, the human s 
actions are modeled using a complex set of decision rules or algorithms. 
These models attempt to explicitly anticipate a human’s actions based on his 
or her sensory inputs, rather than simply capturing approximately the 
overall consequences of these actions, as is done in a macroscopic model. 
Two examples are DORATASK and PUMA, which estimate the overall 
workload on an operator by using detailed representations of the workload 
required to perform specific tasks. A third, very broad, microscopic model 
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is The Man-Machine Integration, Design, and Analysis System (MIDAS). 
These models are described below. 

4.1.3 Model Comparisons 

Table 4.1 identifies five basic applications of human / automation modeling 
and the three approaches outlined above: human-in-the-loop models arid 
macroscopic and microscopic mathematical models. The five categories 
along the top of the table can be loosely described as follows. Situational 
Awareness involves the determination of how the human s mental model of 
a situation matches with the true situation. Flight Planning seeks to 
understand strategic planning and multi-attribute optimization performed by 
humans in connection with a flight. Decision . Making refers to more 
tactical, short-term, flight-related, human decision processes. Task 
Allocation and Workload is concerned with how the human operator 
prioritizes tasks, how tasks affect workload, and how workload affects task 
performance. Finally, Human-Automation Interaction refers to modeling 
the processes by which a human operator obtains information from and 
directs tasks using automation. 


Table 4.1: Human / Automation Tools and Models 



Application 


Approach 

Situational 

Awareness 

Flight 

Planning 

Decision 

Making 

Task Allocation 
& Workload 

Human- 

Automation 

Interaction 

Human 

in 

the 

Loop 

Interview / Observation 
Part-Task Simulation 
Full Mission Simulation 
Shadow Study 
Full System Test 


Macroscopic 

Models 

.: : ;A4Ho<; . 

Decision Rules 
Utility Theory 
Fuzzy Logic 

Time Sharing / 
Capacity Models 
Resource Theory 

, AdHoCt-'r.' 

MxfeiS ' •: 

Microscopic 

Models 


ME) AS 

DORATASK 

PUMA 

1 


Human-in-the-loop studies are real-time and thus outside the scope of this 
review. They are mentioned here for completeness. _ They range from 
focused interviews and observation, to part-task simulation, to full mission 
simulation, to system tests using actual equipment in the field. Shadow 
studies are also useful, in which a new approach is evaluated using actual 
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data feeds in parallel with actual operations. Studies at the interview level 
are generally less expensive, have wider scope, but are less detailed than 
simulation or full system tests. Thus, there is a natural tradeoff between 
level of detail and scope / cost. 

Many ad hoc mathematical models exist, but only a few have been 
developed to stand alone as generic tools for use in more than one study. 
Macroscopic models are often analytical methodologies and equations that 
describe human / automation interaction in general form. As such, these 
models can provide a rough estimate of human capability and performance 
but are often too generic to provide estimates for specific conditions. 

Microscopic models are intended to be high-fidelity representations of 
humans. These models may be specific to a single type of task or situation 
or may attempt to cover a range of conditions. A model such as MIDAS is 
designed to cover a range of tasks including situational awareness, 
planning, decision making, workload analysis, and interaction with 
automation. DORATASK and PUMA, on the other hand, focus only on 
workload. DORATASK models workload by summing the times spent on 
elemental activities such as communicating with aircraft, writing on flight 
strips, etc. PUMA uses a specific listing of tasks along with Multiple 
Resource Theory to estimate workload. Thus, PUMA contains a 
macroscopic model (based on Resource Theory) but is listed here as 
microscopic due to the additional requirement that the operator’s tasks must 
be described in detail and that the computations occur in discrete time 
increments. 

4.1.4 Individual Model Assessment 

MIDAS is a complex numerical simulation model that has already been used 
in several studies. MIDAS includes a set of modules that represent human 
perception, cognitive behavior, and responses to allow analysis of areas 
such as information management, cognition, and workload. MIDAS also 
allows for the inclusion of probabilistic events and errors and is able to 
model interruption and resumption of tasks in single and multiple operator 
interaction. 

Because MIDAS is so complex, it is computationally intensive and needs to 
be adapted to each new application through the definition of input / output 
parameters and a detailed knowledge base. Additionally, it is sometimes 
unclear how accurate MIDAS is in representing human performance. 
Several human/automation studies have already been performed using 
MIDAS, and their results were subsequently verified through human-in-the- 
loop simulations. Still, the flexibility, adaptability, and validity of complex 
models like MIDAS needs to be more fully determined. 

For workload- specific studies, the only models identified for evaluation 
(other than MIDAS) were DORATASK and PUMA. Each model requires 
that operator tasks are defined a priori, and, based on those tasks, an 
estimate of workload is constructed. Example tasks include looking at a 
radar display, pressing a button, and communicating with aircraft. 
DORATASK estimates the overall controller workload for an air traffic 
sector and has been validated in several sectors in the UK. PUMA provides 
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a more detailed output of workload vs. time and is therefore more suited to 
studies investigating specific operating procedures. DORATASK is 
recommended for large-scale workload studies of entire sectors, while 
PUMA is recommended for smaller-scale, detailed studies of specific 
operating environments. 


4.1.5 Recommendations 

The high costs and time associated with human-in-the-loop simulations 
drive the need for mathematical models of humans that can be applied in 
fast-time studies to rapidly examine (and evaluate in a preliminary way) new 
ATM concepts. There are several approaches that can be taken to model 
humans. One approach (microscopic) is to model the entire process from 
sensory input and mental processing to actuation. The other (macroscopic) 
is to represent the human more broadly by describing the transfer function 
between input and output without modeling the details of how the process 
actually works. As is the case for PUMA, it is also possible to combine 
macroscopic and microscopic elements into a single hybrid model. 

Each approach has its benefits and limitations. Specifically, it is important 
to consider the validity and flexibility of a model vis-a-vis different 
applications. A microscopic model like MIDAS provides a very detailed 
description of how the human operates and can provide insight into where 
bottlenecks are and how performance could be improved. However, 
whether the additional level of detail in MIDAS is really needed and whether 
a given version of MIDAS can be extended to cover a novel situation still 
needs to be determined. 

In general, the area of human/automation modeling is clearly one that 
deserves urgent attention and investment of resources. Several areas in 
particular stand out in need of development: 

(a) Macroscopic Models: Because of the need to broadly evaluate how humans 
will react and adapt to advanced and complex air traffic management 
concepts, it is believed here that efforts in macroscopic modeling of human 
performance under a range of conditions may be particularly cost effective 
and pressing at this time. A set of fairly simple models that capture the 
essence of human performance characteristics is probably sufficient for 
concept evaluation at this stage. 

(b) Model Development and Validation Methodologies: Current mathematical 
models of humans are ad hoc, limited, and immature. New, widely- 
applicable models will be needed in the near future. It is important to note, 
though, that much of the required work is of a fundamental nature: in 
addition to the need to develop models themselves, there is also a need to 
better develop the “science” and methodologies by which these models will 
be generated and validated. As an example, there is a need to map out the 
specific space of applications to which MIDAS can and cannot be applied. 
The process by which human-in-the-loop experiments can be used to 
develop and validate simple, broad mathematical models is also immature 
and will require additional research. 

(c) Safety Modeling: A critical area for more research is related to the effects of 
humans and automation on overall system safety. Especially important are 
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tools that model low-probability events (e.g., human blunder or 
misinterpretation of automation) which have a large impact on safety. Exact 
probabilistic models are not possible, although the key problem areas and 
their potential ramifications can be determined. Currently, there is no 
structured way that such modeling is performed, and the need to do so will 
grow as systems become more complex. 

(d) Linking Human/Automation Models to Other Areas: Because of the 
potentially strong constraints that human performance can place on the 
design of an ATM concept, it will be imperative that human/automation 
models be used at some point during the design and evaluation process. 
Currently, however, there are few links between models such as SIMMOD 
and human performance models (one exception is a link between PUMA 
and RAMS). Additional effort is needed to produce links between airspace 
models (e.g., SIMMOD) and human models (e.g., MIDAS). It is 
recommended that these links be created in a modular fashion (e.g., passing 
data between RAMS and PUMA) rather than developing single complex 
models that attempt to model traffic flow, conflict detection and resolution, 
and human / automation issues. 

References 

[1] Wickens, C. D., Engineering Psychology and Human Performance . 

Harper-Collins, 1992. 
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4.2 REVIEWS 

4.2.1 SDAT: Sector Design Analysis Tool (FAA) 

(7/22/96, KK) 

1. Primary Model Category 

Terminal and enroute sector design and controller workload analysis 

2. Summary 

SDAT has been developed by the FAA as an analytic tool for assistance in 
evaluation of changes in airspace design and traffic routing. SDAT takes the 
existing airspace and traffic data, reduces it to more manageable form, and 
allows the user to select, modify and add to the data interactively for 
display. Various customizable analyses based on conflict probabilities can 
then be run to provide metrics such as conflicts, traffic loading, impacts on 
users and sector controller task loads. 

3. Input Requirements 

SDAT can import standard airspace data: 


• Airspace data: sector boundaries, NAVAIDSs, fixes, routes etc. from 
ACES & Adaptation data. 

• Traffic data: from Automated Radar Tracking System (ARTS), System 
Analysis Recordings (SAR), Continuous Data Record (CDR) or the 
Enhanced Traffic Management System (ETMS). 

• Supplemental data: e.g. Special Use Airspace (SUA) 

These are combined for display and analysis and raw traffic data reduced to 
show changes only in direction, climb rate, speed or controlling sector. 
Interactive or text mode modifications of airspace and traffic data can be 
performed for the problem at hand. 

4. Outputs 

The principal outputs are: 

• 3D conflict analysis: 

• potential hotspots for crossing or merging paths where need for 
increased separation exists 

• locations, frequencies and expected per sector and per flight conflict 
potential 

• on screen and text output 

• Traffic volumes in sectors: counts, durations and throughputs 
determined from sector boundary crossings 

• Impacts on users from changes: 


95 



• flight time: based on average speed on each route segment 

• Total flight distance 

• sectors traversed 

• DOC based on average hourly cost for aircraft 

• Sector controller task loads: actions, messages, time required etc. 
calculated from exchanges of HOST data. 

5. Major Assumptions and Limitations 

Unknown. Dependence on recorded traffic data. 

6. Computational Characteristics 

SDAT has been written in C and operates in UNIX and X- Windows with 
the Motif window manager. The platform currently supported is HP 
workstations with HP-UX with future support for SUN systems. 

There are three versions: 

1 . SDAT: Airspace and traffic at a single ARTCC 

2. Regional SDAT: Airspace and traffic at upto 8 contiguous 
ARTCCs 

3 . Terminal SDAT: for terminal facilities 

7. Modularity and Flexibility 
Unknown. Interface to SIMMOD planned. 

8. Status 

Under development and operational test. 

9. Extent of Model Verification 

The core conflict analysis sector ranking has been found comparable to 
ranking by other methods (conflict alerts, operational errors and controller 
surveys). 

10. Principal Applications 

Sector redesign evaluation 

11. Availability 

The software is available from FAA ORLAB. For information contact: 

SDAT Program Manager 
c/o ASD-400 

Federal Aviation Administration 
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800 Independence Avenue SW 
Washington DC 20591 
(202)-358-5223 

12. Information for Model Evaluation 

Kenneth Geisinger (FAA) 

e-mail: kgeisinger@mail.hq.faa.gov 

SDAT Users’ Guide 

SDAT Task Load Model User Manual 

SDAT Brochure 

13. Summary Evaluation 

SDAT (Sector Design Analysis Tool) is an analytic tool for evaluation of 
changes in airspace design and traffic routing. SDAT uses the existing 
airspace and traffic data.lt then reduces the traffic data to remove extraneous 
detail and allows the user to select, modify and add to the data interactively 
for display. Various analyses can then be run to provide metrics such as 
conflicts, traffic loading, impacts on users and sector controller task loads. 

SDAT has been designed to be user friendly with a GUI interface and on- 
line help facilities. Graphical displays of data and analyses results showing 
user selected information are available: 

• Sector geometries 

• Traffic paths 

• Conflict hotspots 

• Flight timelines 

• Sector traffic and task loadings 

SDAT takes the actual observed tracks, simplifies them into linear segments 
and determines the crossing points. Conflict probabilities for these points 
are then determined by assuming the aircraft to be randomly distributed in 
time along these tracks. The analysis is performed mathematically in a single 
run as compared to simulations which use multiple time-stepping runs with 
randomization (Monte-Carlo) to get statistical measures. 

4.2.2 DORATASK 

(Last update: 08/08/96 KK) 

1. Primary Model Category 

Sectorwise controller workload modelling 

2. Summary 

DORATASK is a fast-time simulation developed by the CAA(UK) for 
evaluating sector capacity based on controller workload limits by 


97 


systematically summing up the time the controller might spend on 
observable and non-observable tasks for each category of traffic in a sector. 
It follows from the simulation model RECEP(US) and complements CAA's 
CATSIM model. It allows prediction of capacity changes resulting from 
changes in manning levels, route structures or relative traffic loadings, ATC 
procedures or equipment, and airspace re-sectorization. DORATASK 
defines the capacity of a sector as that which creates a level of workload 
equal to a specified level (e.g 48 occupied minutes per hour). 

3. Input Requirements 

Sector geometry, routes, task timings (determined from video, microphone 
recordings or otherwise) etc... 

4. Outputs 

Workload limited sector traffic limits. 

5. Major Assumptions 

Availability of typical activity times. Designed for UK sectors and 
procedures etc.. 

6. Computational Characteristics 

Machine and system: Not known 

Learning effort: High; training needed, in addition to familiarity with 
sectors, traffic and procedures. 

No documentation is available. 

7. Modularity and Flexibility 

Apparently standalone. Extension to dual controller sectors being developed 
as well as other algorithmic enhancements. 

8. Status 

The model is currently being used by CAA for UK sectors. Since 1992 it 
has been used for caqpacity assesment of the London Area Traffic Control 
Centre (LATCC), Scottish area (ScATCC) and the UK’s CCF. 

9. Extent of Model Verification 

The model has been calibrated against many sectors in the UK with other 
capacity methods or empirical data. Caution is urged by the CAA in 
applying the model to sectors which it hasn’t been calibrated for, as 
unexpected interactions may arise. 

10. Principal Applications 

Sector capacity assesment specific to the UK. 
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11. Availability 

Available from the CAA with permission. 

12. Information for Model Evaluation 

Amab Majumdar 
Eurocontrol 

e-mail: amab.majumdar@eurocontrol.fr 

13. Summary Evaluation 

The DORATASK method has been developed by the UK CAA's Directorate 
of Operational Research and Analysis (DORA). The DORATASK method 
models workload by summing the times spent on elemental activities such 
as communicating with aircraft, writing on flight strips, communicating 
with neighbouring sectors, etc. The capacity of a sector is then the 
maximum number of aircraft which would cause the controller to be 
saturated for no more than a specified percentage of time. This works well 
for predicting sector capacity in today's system where many fine details of 
the system are known, but there are difficulties in applying it to future 
systems where such details are not yet known. 


4.2.3 MIDAS: Man-Machine Integration, Design, and Analysis System 
(Last update: 3/25/96 JKK, KK) 

1. Primary Model Category 

Human factors and performance analysis of complex man-machine systems. 
Also includes extensive CAD capabilities for equipment design and avionics 
layout. 

2. Summary 

MIDAS is a set of modules that allow simulation of humans interacting with 
crew station equipment, vehicle dynamics, and a dynamically generated 
environment. Computational models of the operator, the crew station, and 
the environment of the vehicle are implemented with emphasis on operator 
performance under mission conditions. Detailed models of human 
perception, cognitive behavior (including heuristic knowledge bases and 
decisions), and responses allow analysis of critical areas of human 
performance such as information management, cognition, and workload. 
MEDAS also allows for the inclusion of probabilistic events and errors and 
is able to model interruption and resumption of tasks in single and multiple 
operator interaction. Several adaptations of MIDAS to the commercial 
aviation domain have been developed, including Taxi-MIDAS and Air- 
MIDAS. 
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3. Input Requirements 

Required inputs depend on the modules being used. In Air-MIDAS, inputs 

include: 

• The mission and activities to be performed, including probability 
distributions describing when events occur. 

• Operator characteristics, including knowledge bases and decision rules. 

• Additional modules can be used, incorporating inputs such as 
anthropometric models, vehicle dynamics, and perception / attention 
models. 

4. Outputs 

• Human factors analysis such as reachability and visibility 

• Visualization of simulated mission scenario (time lines of events and 
activities) 

• Measurements of mission and operator performance 

• Information requirements analysis 

5. Major Assumptions 

The human operates according to a set of definable decision rules. 

6. Computational Characteristics 

• Platform: Silicon Graphics Onyx with Reality Engine-2 Graphics. 
MIDAS can also run on lower-end SGI workstations. 

• Operating System: IRIX 5.2 

• Memory: 

• Software Requirements: Allegro Common LISP 4.2 with CLIM 2.0 
from Franz. Inc. is required for the LISP components of the code. Other 
components are written in C and C++. 

• Documentation: Description of the various modules and their inputs and 
outputs. A users manual is currently under revision. 

• Startup Effort: High User Interface: Adequate. GUI-based, under 
continuing development 

7. Modularity and Flexibility 

MEDAS is modular, with the user able to specify which modules are active. 

A list of components is attached. 

8. Status 

Under continual development, not mature. 
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9. Extent of Model Verification 

Data generated by MIDAS for a problem investigating descent clearance 
timing have been compared to full-mission LOFT-type data and found to be 
consistent. 

10. Principal Applications 

Taxi-MIDAS preflight checklist study 

Air-MIDAS has been used to examine the effect of the time at which a 
descent clearance is given (relative to the programmed top-of- 
descent point) on the choice of descent mode (i.e., autopilot vs. 
flight management system reprogram). Also examined were the 
effect of voice communications relative to datalink and pilot ability to 
successfully initiate the descent before reaching the top-of-descent 
point. 

Westinghouse nuclear power plant comparison of paper and electronic 
procedure aiding 

Richmond, CA emergency 911 dispatch workstation layout 

High Speed Civil Transport flight deck analysis 

Air Warrior air crew protective suit design 

Short Haul Civil Tilt Rotor cockpit and crew procedure design. 

Helmet Mounted Display analysis 
Liquid Crystal Display analysis 

11. Availability 

MIDAS is available through the NASA Ames Research Center and Sterling 
Software. Contact: Kevin Corker, (415)-604-0055, 

kevin_corker@qmgate.arc.nasa.gov 

12. Information for Model Evaluation 

"Army-NASA Aircrew/Aircraft Integration Program: Phase VI A3I Man- 
Machine Integration Design and Analysis System (MIDAS) Detail 
Design Document." 

Corker, K. and G. Pisanich, "A Multiple Agent Model of Human 
Performance in Automated Air Traffic Control and Flight Management 
Operations", Proceedings of the Fifth International Conference on 
Human-Machine Interaction and Artificial Intelligence in Aerospace, 
Toulouse, France, Sept. 27-29, 1995. 

Corker, K. and G. Pisanich, "Analysis and Modeling of Right Crew 
Performance in Automated Air Traffic Management Systems", 
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Proceedings of the Sixth IFAC/IFIP/IFORS/IEA Symposium on 
Analysis, Design, and Evaluation of Man-Machine Systems, 
Cambridge, MA, June 27-29, 1995. 

A summary of MIDAS is also provided at its website.: 

http://ccf.arc.na sa.gov:80./af/aff/midas/MIDAS_home_page.html 

13. Summary Evaluation 

MIDAS is a collection of experimental computational tools for evaluating 
human factors and performance analysis of complex man machine systems. 
The model is made up of several modules that can be independently turned 
on or off according to the problem under consideration. Modules include 
models of human vision, attention, perception, internal representation of the 
world, decision rules, and responses. Aircraft dynamics, guidance, 
environment, and terrain data may also be included. 

For a given problem, the user provides a model of the environment, events 
that are to occur, and probability distributions. Also provided are the 
decision rules the human uses in acting on the information that is observed. 
MIDAS then runs through a simulation in 100 msec time increments, 
simulating the occurrence of events and the actions taken by the human in 
response. A timeline showing when events and actions occurred is then 
provided as output. By running many simulations in a Monte Carlo fashion, 
statistical results can be obtained. 

MIDAS has been used to examine the effect of the time at which a descent 
clearance is given (relative to the programmed top-of-descent point) on the 
choice of descent mode (i.e., autopilot vs. flight management system 
reprogram). Also examined were the effect of voice communications relative 
to datalink and pilot ability to successfully initiate the descent before 
reaching the top-of-descent point. 

Some of the limitations mentioned in the design document are: 

• Difficult to Use 

• Extremely Data Intensive 

• Unintegrated user interfaces 

• Lack of validation/verification of models 

• Extremely slow speed of simulation 

• Many undeveloped components 

MIDAS is a very complex model intended to simulate complex situations 
and human cognitive processes. It has been used in some limited studies 
using a subset of the available modules. Verification of results will be a 
significant challenge in the future. 

14. MIDAS Modules 

1. Cockpit Design Editor (CDE) 

2. Anthropometric Model (Jack’) 

3. Vision Modeling Tools 
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4. Agents(including Communication Methods and Biographers 

5. Pseudo Agents 

6. Activity Representation 

7. Simulation Executive 

8. Mission and Standard Operating Procedures (MSOP) 

9. Equipment Model 

10. Flight Dynamics 

11. Guidance 

12. Terrain 

13. Environment and other Objects 

14. Vision 

15. Perception/Attention 

16. Updatable World Representation (UWR) 

17. Daemons 

18. Decision-by-rules 

19. Decision-by-algorithm 

20. Symbolic Operarator Model (SOM) 

21. Scheduler 

22. Task Loading Model (TLM) 

23. Motor 

24. Anthropometric Model for Simulation (Jack Agent) 

25. Visual Editor and Simulation Tool (VEST) 

26. User Interface 

27. Equipment Editor 

28. Activity Editor 

29. Statistics 


4.2.4 PUMA (DRA) 

(08/07/96 KK, to be updated) 

1. Primary Model Category 

Human Factors: workload modeling. 

2. Summary 

PUMA is a method and toolset for the modelling, in fine detail, of human 
workload. It was developed for NATS to help them in their work on future 
upgrades to NERC (New En Route Centre, the en route air traffic control 
centre for the London FIR). PUMA allows expressing controller tasks, 
defining a scenario of aircraft movements, and calculating the workload that 
results as the scenario plays through and the tasks are executed (and then 
altering tasks, repeating the calculation, and seeing the changes in 
workload). It uses the Wickens Multiple Resource Theory approach to 
calculate workload, and expresses this as a graph of workload against time. 

3. Input Requirements 

Required tasks; Air traffic scenarios; other data files; video recordings etc... 
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4. Outputs 

Graph of workload against time. 

Graphical simulation of activities with timelines. 

5. Major Assumptions 
Unknown 

6. Computational Characteristics 

PUMA is built on top of a proprietary _ object-oriented modelling 
environment (Lisp-based) and runs on Unix workstations and Mac 
workstations. 

7. Modularity and Flexibility 
Unknown 

8. Status 

The latest version is 2.2b. Roke Manor Research licences the system to 
third parties, as a fully supported product as well as supporting NATS s 
use. 

9. Extent of Model Verification 

Unknown 

10. Principal Applications 

PUMA has been used for UK ATC studies, and also under contract to Lfv 
(the Swedish CAA) to analyse the complete Swedish ATC system (tower, 
TMA and en route), and licences have been taken by Spain (AENA, the 
Spanish CAA), and Eurocontrol. 

AENA (The Spanish CAA) has been working with RAMS for enroute 
studies. For workload analysis purposes, PUMA was hooked to RAMS the 
following way: RAMS was run normally. Each time a controller activity is 
generated in RAMS, it is sent to PUMA as a PUMA event. RAMS was 
suitably modified to detect task triggers. 

PUMA has also been used for non-ATC purposes. In principle it’s 
applicable in any area where tasks can be well defined, and the resulting 
workload needs to be determined. 

11. Availability 

Roke Manor Research (a contract R&D company, part of the Siemens 
organisation) developed PUMA for NATS during 1993, and have been 
developing it for them under contract since. The latest version is 2.2b. Roke 
Manor Research licences the system to third parties, as a fully supported 
product. 
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12. Information for Model Evaluation 

Paul Day 

Principal Account Manager 
Roke Manor Research 
e-mail: Paul.Day@roke.co.uk 

Rob Whitaker 

CAA/NATS Air Traffic Management Development Centre 
Hum, UK 

e-mail: robw@dasr.demon.co.uk 

13. Summary Evaluation 

PUMA is a method and toolset for finely detailed modelling of human 
workload. It was developed for NATS for their work on future upgrades to 
NERC (New En Route Centre, the en route air traffic control centre for the 
London FIR). NERC will have its capacity enhanced by the provision of 
computerised support tools for the controllers, and NATS needed a desktop 
system to evaluate and filter out ideas, in terms of their effect on controller 
workload. 

PUMA is a means of expressing controller tasks, defining a scenario of 
aircraft movements, and calculating the workload that results as the scenario 
plays through and the tasks are executed (and then altering tasks, repeating 
the calculation, and seeing the changes in workload). It uses the Wickens 
Multiple Resource Theory approach to calculate workload, and expresses 
this as a graph of workload against time. 

PUMA is a suite of integrated tools, supporting a range of functions 
including task analysis (including the analysis of video recordings - it has a 
fully integrated video analysis system), task synthesis, scenario definition, 
task sequence definition, and workload calculation. 
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5.0 CQST/BENEFIT ANALYSIS MODELS 

5.1 Review of Cost/Benefit Analysis Models 

5.1.1 Definition 

A new development or modification of the ATM system,, such as Free 
Flight, is only likely to be earned to fruition if some substantial benefits can 
be anticipated as a result of its implementation. In addition to benefits there 
will also be costs that inevitably accrue during both the implementation stage 
and in subsequent operations as well. If objective judgments of worth are 
to be made, in the process of deciding whether or not to proceed with 
implementation, the new development or modification should be evaluated 
by comparing some quantitative measures of the anticipated benefits against 
the projected costs of implementation. Also, both the non-recurring costs of 
development and the recurring costs of operation should be accounted for as 
well as the time sequencing of costs and benefits as they might accrue. 

Cost/benefit models are a means by which quantitative projections of both 
costs and benefits can be realized. In particular, appropriate cost/benefit 
models can permit the extrapolation of costs over time as well as projections 
of financial measures of the benefits that may be expected. Hence, 
appropriate cost/benefit models can provide the objective means for judging 
the net worth of proposed new developments or modifications of the ATM 
system. 


5.1.2 Cost/Benefit Models 

There is only minimal general-purpose capability currently available for 
cost/benefit analysis of the ATM system. Two models were identified that 
apply to this area, and only one of these is at a level of maturity that would 
enable it to be exercised by a user. Each model will be discussed in turn. 

1 ACIM (Air Carrier Investment Model): This model, a part of NASA’s 
AS AC (Aviation Systems Analysis Capability) initiative, generates 
estimates of the future demand for air travel from supply and demand 
factors based on projections of future economic conditions and 
operating characteristics of air carriers. From these the model creates 
estimates of future airline industry economic conditions, aircraft 
industry production demands and other economic parameters related to 
the economic health of both the airline and the aircraft industries. 
Examples of some typical economic parameter forecasts that can be 
created using the model are: 1) domestic and international travel demand 
in terms of revenue passenger miles, 2) the associated operating 
margins for air carriers, and 3) the total projected air carrier fleet size. 
The model will forecast these types of variables under various scenarios 
such as high economic growth and low unemployment, an oil price 
shock, and/or a fare war. 

2 NARIM: This model is currently in its initial phase of development at 
the FAA. A primary goal of the effort is “to provide an analysis 
framework that enables the assessment of the operational, investment 
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and architectural implications of new operational concepts from the 
perspectives of the integrated aviation community” [1]. .NARIM is best 
characterized as a modeling framework into which existing models will 
be integrated and combined with new models to permit extensive 
evaluations of new ATM concepts or modifications. It is intended to 
take maximum advantage of the modeling capability that already exists 
in the areas of airport and airspace operations simulation, conflict 
resolution, workload measurement, and human factors. Four functional 
areas will be addressed by the prototype- 1) schedules and trajectories, 
2) temporal mapping, 3) resource loading, and 4) performance and 
benefits analysis. Many existing models will be used either directly or 
in modified form to create the capabilities required in the first three 
areas. Extensive new modeling effort is anticipated in the fourth area. 

5.1.3 Model Comparisons, Effectiveness and Validity 

The most significant differences between ACIM and NARIM are their 
relative level of maturity and the scope of their capabilities. ACIM is quite 
mature and has been in use for about four years. Its implementation is in 
the form of either a Lotus 1-2-3 or an Excel spread sheet. The program is 
quite user friendly and can be readily exercised after studying the associated 
User’s Guide for a few hours, assuming modest knowledge of the Lotus 1- 
2-3 or Excel software application programs. In contrast, the NARIM model 
is under development and not available to potential users at the present time. 

ACIM is an effective tool for projecting growth and demand in both the 
airline and commercial aircraft industries. The model utilizes high level 
economic parameters (such as population growth, fare yields and fuel 
prices) as inputs, to create projections of future air travel demand and airline 
cost functions. The model accounts for future productivity growth through 
projections of both human productivity enhancement factors and equipment 
efficiency gains. Human productivity gains are accounted for through 
reductions in labor price parameters over time. The model also predicts 
airline costs using parameters representing the aggregate characteristics of 
airline fleets and other factors to describe airline networks. The projections 
of air travel demand and airline costs are than combined in the model to 
create industry-level forecasts of future revenue passenger-miles, number of 
aircraft in the US fleet and airline operating margins. The model is 
particularly useful for evaluating the projected economic benefits that could 
be expected as a result of improvements in equipment efficiency or 
modifications of operating procedures that might be achieved from of the 
introduction of new technology. 

ACIM’s validity rests on the extensive historical data bases from which it 
was created including the US Department of Transportation’s (DOT) Origin 
and Destination (O&D) data record and airline cost data from DOT Form 41. 
The O&D data, as well as Census Bureau data on the economic 
characteristics of Standard Metropolitan Statistical Areas surrounding 85 
major airports, were used to model the air travel demand for each of 13 US 
passenger air carriers (and/or their various manifestations through mergers 
and acquisitions) from 1970 to 1990. Similarly, the Form 41 data and other 
sources provided information for cost models for each of the 13 air carriers. 
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The ACIM model accurately portrays the recent history of economic 
evolution of the airline industry by capturing the data history in relatively 
simple regression models. The user supplies inputs which characterize a 
future economic supply and demand situation at high levels and the model 
projects the airline and aircraft industry economic situation from these inputs 
using its econometric models. Hence ACIM is an accurate extrapolator of 
current industry characteristics, which allows a user to explore the 
consequences of assumed future economic conditions and industry 
characteristics through judicious choices of input variables. 

Because the NARIM model is currently only in the development stage it is 
not possible to evaluate its effectiveness and validity in a fashion similar to 
the evaluation of ACIM. However, the goals that it aspires to suggest that, 
if successfully developed, NARIM will provide capabilities which are more 
extensive than those of ACIM and which will address many current needs in 
terms of cost/benefit analysis as well as many other areas of evaluation of 
ATM concepts 

5.1.4 State of the Art of Cost/Benefit Modeling 

To effectively characterize the current state of the art in cost/benefit 
modeling of ATM it is important to first understand the need for this class of 
models. In evaluating any new ATM system concept it is important to 
balance the estimated costs of implementation and operation against the 
expected benefits. The timing of costs and benefits must also be accounted 
for since costs are likely to be paid initially, while benefits are typically 
received over the long term. This calls for the use of appropriate 
discounting practices that render “commensurable” dollars expended or 
received at different times 

Although it is likely to provide useful results in a variety of contexts, 
cost/benefit modeling will be particularly important for evaluating the 
various manifestations of Free Flight that are likely to emerge in the future. 
For example, the current Free Flight concept envisages a major change in 
the way Traffic Flow Management (TFM) is executed for flights into major 
hub airports. It is likely that there would be considerable benefit if 
increased landing capacities are realized but, absent such an increase, any 
benefit in this area must presume that the current approach for executing 
TFM in the USA is inefficient; and that the new TFM approach, under Free 
Flight, will eliminate these inefficiencies. Evaluating this conjecture 
requires a definition of exactly how the old and the new TFM methods 
would work, studies to document the current TFM problems at major hubs, 
and the capability to evaluate performance and costs. 

Similarly, the current Free Flight concept envisages an adaptive 
sectorization whereby sector sizes and manning can be quickly redefined to 
allow a re-routing of enroute flows around weather, etc. so as to avoid 
violations of sector workload limits. There is currently a re-routing tool 
available, called Automatic Demand Resolution (ADR), which has the 
potential to re-rout traffic equitably subject to sector workload limits. This 
new tool should be studied to see if the inherent problems in training 
controllers to work in an adaptive sectorization mode are worthwhile. 
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Cost/benefit analysis will be the primary tool for evaluating effectiveness of 
this approach. 

As the Free Right ATM concept evolves, each new concept is likely to 
require evaluation in terms of costs and benefits. Three main categories o 
participants are likely to receive significant benefits and incur costs from 
changes in the ATM system. They are: 

a) Aircraft Operators (Airlines, General Aviation, Military) 

b) Airline Passengers/Shippers 

c) ATM Service Provider 

Each may receive different types of benefits and each will incur costs in a 
different fashion. A correct accounting should determine both the costs and 
benefits attributable to each category of participant. For example, a new or 
modified ATM system is likely to involve investments in both ground-based 
and airborne equipment. Typically, ground-based equipment costs will be 
borne by the ATM service providers, while airborne costs must be absorbed 
by aircraft operators. In corresponding fashion, other costs such as 
personnel training, system maintenance, software costs etc. will accrue to 
ATM providers or aircraft operators according to their respective roles in the 
ATM system. 

The benefit most likely to accrue from a new ATM system, such as Free 
Flight, is time savings which will result from increased capacity of the ATM 
system. For air trips between certain terminals, in today s ATM system, 
there are built-in time delays due to capacity constraints at peak traffic times. 
In this context, time delay is defined as the excess time to accomplish a trip, 
over the trip time for a traffic-free flight. 

Increasing the capacity of the ATM system should allow a direct decrease in 
the aggregate delays currently imbedded in nominal schedules as a result of 
capacity constraints at peak traffic times. For aircraft operators, time 
savings translate into reduced fuel and marginal aircraft operating costs, 
reduced interrupted trip expenses, and reduced costs for irregular 
operations. For passengers, the time savings should be translatable into 
equivalent cost savings. For business travel it is likely that this time-to- 
cost-savings translation can be accomplished rather directly though 
personnel costing. For personal and pleasure travelers the translation is 
more subjective and may require some form of rationalization to relate time 
delays to equivalent costs. 

When viewed in the context of these needs it is clear that the existing models 
have limited capability and there is considerable need for new models. Table 
5 1 illustrates the various categories of need for cost models and the ability 
of current models to fulfill the need. As can be seen, only the commercial 
air carrier category is supported in the capital, operating cost, and delay cost 
areas and, as indicated by the (+) signs in the boxes, additional modeling 
effort will be required to adapt ACIM so that it could appropriately satisfy 
the requirements in these areas. New modeling efforts are required to 
satisfy the needs in the other areas. 
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Table. 5.1 Model Requirements 


Cost Category 

ATM Service 
Provider 

Commercial 

Air 

Military Air 

GA 

Capital Costs 

Need Model 

ACIM(+) 

Need Model 

Need Model 

l?eS3i§wSI 

Need Model 

ACIM(+) 

Need Model 

Need Model 

Delay Costs 

Not Applicable 

ACIM(+) 

Need Model 

Need Model 


5.1.5 Recommendations 

As discussed earlier, there are three categories of participants in the ATM 
system who can reap benefits and/or incur costs. A cost/benefit mode 
toolkit should include capabilities to analyze costs and benefits for each of 
these participants. The following sections summarize the identified 
modeling needs for each of these categories. 

ATM Service Provider Tost Models: The costs which must be borne by the 
ATM provider are likely to constitute a major portion of the total expense 
incurred using any new ATM concept. Non-recurring costs will accrue for 
capital equipment expenses for the initial development and construction ot 
facilities as well as the initial training expenses necessary to implement the 
concept. Recurring costs will accrue for operations and maintenance 
personnel, replacement equipment, and continual training of personnel to 
maintain proficiency. For any particular ATM concept, models will be 
necessary to allow the evaluation of costs incurred in relation to the benefits 
that may accrue as a result of implementing the concept. These models 
should allow the incorporation of projected growth of traffic and the 
associated required upgrading of the system over time. 

As discussed above, such items as the cost aspects of traffic flow 
management and of adaptive sectorization must be included if Free Flight is 
to be effectively evaluated. An area of particular importance will be costs 
and potential savings that may accrue due to partial automation and operator 
assistance. Models must be capable of quantifying the tradeoffs between 
partial automation, operator assistance and manual operation of various 
elements of any ATM concept. 

Aircraft Oneratnr Tost Models: The operators of aircraft (Airlines, Military 
GA) are likely to be the major beneficiaries of any new ATM concept and 
cost models of these constituencies will be necessary to quantify projections 
of benefits and costs. Models for airline personnel costs and marginal 
aircraft operating costs are the most readily available of these three 
categories. These cost models must facilitate the evaluation of airline 
operator cost savings resulting from reductions in delays attributable to 
ATM capacity increases. Models for military and GA costs/benefits will be 
more difficult to realize and are likely to be more subjective in nature. 
Additionally, all models must quantify the capital expense of new airborne 
and ground based equipment required to allow aircraft operation in any new 
ATM system, as well as recurring costs for maintenance and personnel 

training. 
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The ACIM model discussed earlier embodies much of the required 
capability needed for airline cost modeling, although the current 
implementation of ACEM may not provide some of the data outputs which 
might be desired in specific studies of airline costs. Certainly, any model 
development in this area should take advantage of the considerable expertise 
already embodied in ACIM and should build on the existing capability. For 
military and GA costs, new models will be required. 

Currently missing from the ACIM model is the capability to evaluate the 
cost savings that might accrue due to reductions in travel times or airport 
delays. Such capability could be realized by augmenting ACIM, and/or 
creating a companion capability, to model delays and their effects on 
operator costs. The current ACIM structure is likely to be amenable to such 
an augmentation of its capabilities and the result is likely satisfy the need for 
effective evaluation of operator benefits which would result from Free 
Right or other changes in ATM operations. 

Passenger/Shipper Cost Models: As discussed earlier, it should be possible 
to create cost models for business travelers directly from personnel costs 
attributable to delays. Similarly, cost models for shippers should reflect the 
marginal costs for shipping that accrue as a result of delivery guarantee 
costs and/or personnel expenses which result from delayed shipments. In 
addition, some means of quantifying equivalent costs for personal and 
pleasure travel must also be determined. These costs are far more subjective 
in nature and not as readily and objectively defined as for business travelers 
and shippers. Models which facilitate parametric studies over ranges of 
possible values may be the most useful approach for these classes of 
travelers. 

Common Requirements for Models: All of the cost/benefit models should 
be capable of and/or adaptable to both deterministic and probabilistic 
studies. In many instances there will be a need for a direct evaluation of 
costs based on a specific set of parameters. For example, an aircraft 
operator model should be capable of determining the change in marginal 
costs for a given airline which result from an ATM capacity increase for a 
specific trip between two cities. In addition, the aircraft operator model 
must also be able to create statistical estimates of relevant costs. An 
example here might be the determination of the expectation of future dollar 
savings for all airlines operating in a Free Right environment. In this 
instance the model would incorporate probabilistic models of weather, 
economic forecasts over both time and geographical regions, and possibly 
projections of technical capabilities and costs affecting levels of automation 
for the ATM system concept. 

To be most useful cost models should be amenable to integration with other 
models. For example, the conflict models described earlier are essential for 
quantifying capacity increases that may be achievable with any particular 
ATM concept. The cost models described in this section create the 
relationships between capacity increases and cost benefits to various 
constituencies. Implicit here is the need for a framework or medium to 
facilitate the integration of the various types of models. Such a framework 
would establish the initialization and information transfer facilities between 
models necessary for the wide range of tradeoff studies which are likely to 
be required to evolve a truly effective ATM concept. This integration 
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framework must function much like a modem computer operating system, 
creating appropriate user interfaces, managing resources, facilitating 
interchange of information and creating an appropriate environment for 
effective utilization of the various models and associated data bases. 

The planned development of NARIM addresses many of the needs for 
integration of models. The NARIM development plan makes specific 
reference to maximizing the utilization of existing models to create a 
cost/benefit modeling capability. Hence the concept of NARIM itself 
embodies the need for effective integration of numerous models. 

Finally, it is important to identify the need for models of varying simplicity 
and/or accuracy. Many issues can be addressed and questions successfully 
answered with relatively simple models which are inexpensive to both 
develop and exercise. Conversely, there are also instances when only 
extensive, detailed and more expensive models will suffice. Hence there 
should be at least two levels of modeling detail available for users. One 
level of modeling fidelity should be capable of quickly and efficiently 
answering questions at a rough order of magnitude level of accuracy, 
consistent with determining overall feasibility and direction for a concept. A 
second level of capability should be capable of answering more extensive 
questions at a much higher level of accuracy, consistent with detailed 
planning and scheduling of a new implementation. 

Reference 

1. Bradford, S. and W. Colligan, “National Airspace Resource Investment 
Model: Needs Analysis and Operational Concept Report”, Draft Report, 
Federal Aviation Administration, April 1996. 
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5.2 Reviews 

5.2.1 ACIM: The AS AC Air Carrier Investment Model 

(Last update: October 8, 1996 ) 

1. Primary Model Category 

Cost/Benefit and Investment Model 

2. Summary 

ACIM is a tool for projecting growth and demand in both the airline and 
commercial aircraft industries. The model utilizes high level economic 
parameters (e.g. fare yields, population growth and labor costs) to create 
projections of future air travel demand and airline cost functions. It also 
accounts for future productivity growth through projections of both human 
productivity enhancement factors and equipment efficiency gains. Human 
productivity gains are accounted for through reductions in labor price 
parameters over time. The model also predicts airline costs using 
parameters representing the aggregate characteristics of airline fleets and 
other factors to describe airline networks. The projections of air travel 
demand and airline costs are then combined to create industry-level forecasts 
of future revenue passenger-miles, number of aircraft in the US fleet and 
airline operating margins. The model is particularly suitable for projecting 
the economic benefits that could be expected as a result of improvements in 
equipment efficiency or modifications of operating procedures that might be 
achieved from the introduction of new technology. 

The ACIM econometric models are created from a number of databases 
including the US Department of Transportation's (DOT) Origin and 
Destination (O&D) data record, airline cost data from DOT Form 41, and 
Census Bureau data on the economic characteristics of Standard 
Metropolitan Statistical Areas surrounding 85 major airports. The O&D and 
Census Bureau data were used to model the air travel demand for each of 13 
US passenger air carriers (and/or their various manifestations through 
mergers and acquisitions) from 1970 to 1990. Similarly, the Form 41 data 
and other sources provided information for cost models for each of the 13 
air carriers. Included in the cost models are each earner s labor costs, the 
characteristics of its network and its fleet characteristics in terms of numbers 
and size of various aircraft and efficiency factors for each type of aircraft. 

ACIM’s validity rests on the extensive historical data bases from which it 
was created. It accurately portrays the recent history of economic evolution 
of the airline industry by capturing the data history in relatively simple 
regression models. The user supplies inputs which characterize a future 
economic supply and demand situation at high levels and the model projects 
the airline and aircraft industry economic situation from these inputs using 
its econometric models. Hence ACIM is an accurate extrapolator of the 
current industry characteristics, which allows a user to explore the 
consequences of assumed future economic conditions and industry 
characteristics through judicious choices of input variables. 
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3. Input Requirements 

The user inputs a series of values which project future annual changes in: 

• Demand Variables-fare yield, national income, population growth, 
and unemployment rate 

• Supply Variables-labor, energy, materials, and capital costs 

• Network Factors-stage length and load factor 

• Capital Attributes-average seats/aircraft, aircraft age, % jet aircraft, 
% wide body aircraft 

Airline target operating margins over future time may also be input. 

4. Outputs 

The program outputs are future projections of: 

• Domestic and international travel demand for U.S. scheduled 
passenger air carriers in revenue passenger miles 

• Size of the total U.S. scheduled passenger air carrier fleet in 
numbers of aircraft 

• Operating margin for U.S. scheduled passenger aircarrier fleet in 
percent 

5. Major Assumptions 

ACIM is based on the assumption that a model, based on data over the 
period of 1979 through 1990, can be used to create credible estimates of 
future conditions for the airline and aircraft industries. The validity of this 
assumption is, to a large extent, dependent upon the quality of the 
information used to create the model. 

The model projects air travel demand forward using a regression model 
created from past information. Data for the demand model is based on the 
U.S. Department of Transportation’s Origin and Destination record for 
tickets: coupled with the size and prosperity of the air travel market, inferred 
from standard economic models for regions surrounding 85 airports. 
Similarly a cost model was developed to account for labor, energy, 
materials and capital for 13 U.S. air carriers and/or their evolved 
manifestations in the period from 1979 through 1990. The primary capital 
element in the model is aircraft and aircraft productivity factors (e.g. 
increased fuel economy) are specifically accounted for in the model. Two 
additional factors, average stage length and passenger load factor, arc used 
to model the effects of each air carrier’s network characteristics on costs. 
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The demand and cost models are configured so that demand and costs can 
be projected forward in a fashion such that future total industry travel 
demand, air fleet size, and operating margin can be calculated. 

6. Computational Characteristics 

The model has been implemented as a spread sheet and is available to run as 
an application program on either Lotus 1-2-3 or Microsoft Excel. Most 
current personal computers are capable of running the program. 

7. Startup Effort 

The model can be used after only a few hours study of the users guide. 

8. Modularity and Flexibility 

The program was written to produce some rather specific outputs from a set 
of input variables. Deviations from this specific set of input and output 
variables would require reprogramming of the model. 

9. Status 

The model has been developed and tested extensively. 

10. Extent of Model Validation 

The model is an accurate replica of past performance and conditions for the 
U.S. airline industry. Its validity for projecting future conditions in the 
industry depends upon a continuance of these same kinds of economic 
conditions in the future. 

11. Principle Applications 

The principle application of the model is to study the relative advantages 
which new aircraft technologies can bring to the airline and aircraft 
industries. 

12. Availability 

Upon request to Peter F. Kostiuk, Logistics Management Institute 

13. Information for Model Evaluation 

Model description, users guide, and exercise of the model 

14. Contact Point 

Peter F. Kostiuk 
Logistics Management Institute 
2000 Corporate Ridge 
McLean, VA 22102-7805 
Phone: (703)917-7427 
Email: pkostiuk@lmi.org 
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15. Summary Evaluation 


ACIM was specifically developed as a tool for estimating the relative 
benefits that might accrue to various new technologies which might be 
developed to increase the efficiency and/or productivity of future aircraft. 
Hence, ACIM is not a cost/benefit model as such, but might better be 
characterized as a module that could be embedded within a larger cost 
benefit model for the purpose of calculating airline industry supply/demand 
variables. The model is very easy to use and requires only minimal learning 
effort on the part of a new user. 

5.2.2 NARIM: The National Airspace Resource Investment Model 

1 . Primary Model Category 

Modeling and analysis of future aviation system concepts 

2 . Summary 

The purpose of the National Airspace Resource Investment Model 
(NARIM) is to provide NASA and the FAA with the modeling and analysis 
capability to analyze airspace concepts associated with future advances to 
the National Airspace System (NAS). The system is being developed to 
also provide a NAS perspective to the research and investment allocation 
process. In providing this perspective, NARIM is to include the modeling 
and analysis of current and potential operations, the engineering impacts of 
future systems and the ability to trade requirements within a system and 
across systems and procedural investment alternatives. 

The NARIM system consists of three interrelated parts: 

1. Operational modeling to analyze the movement of aircraft through the 
NAS to determine the impacts that new concepts will have on the overall 
performance of the NAS. 

2. Architectural or technical modeling, implemented through a series of 
executable engineering modeling capabilities, provides a means of assessing 
how procedural/system changes affect the hardware/software components 
of the NAS infrastructure (both FAA and users). This element of NARIM 
also provides an understanding of how the NAS components interact with 
each other based upon their performance characteristics and the flow of 
communication, navigation and surveillance (CNS) data and potential 
decision support system solutions between them. 

3. Investment analysis modeling provides the user with a methodology to 
cost effectively trade between alternatives for a system, trade requirements 
within a system and across system and procedural investment alternatives, 
trade between services to be provided/included into the NAS, balance risk, 
and assess the investment decision as a of part of a total research portfolio. 

Figure 5.1 provides a high-level functional flow diagram for NARIM. 
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Figure 5.1 - NARIM Functional Flow Di^grum 


NARIM is being built incrementally through a series of three builds. The 
first build, the NARIM prototype, has been completed and is currently 
being applied by the FAA’s Program Analysis and Operations Research 
Division for a study of NAS and ETMS data variability. The NARIM 
prototype analysis capability is based on four functions: schedule and 
trajectory generation, temporal mapping to the NAS, .NAS resource loading 
simulation, and NAS performance and benefit analysis. 

Builds 2 and 3, which have not yet been initiated, will implement a large 
number of enhancements and new capabilities. 


3 . Input Requirements 

NARIM input requirements will vary depending upon the particular analysis 
being performed. They include: for operational analysis inputs on weather, 
aircraft performance, NAS infrastructure data, NAS demand and 
airport/TFM Constraints; for architecture and infrastructure analysis inputs 
on NAS subsystem performance characteristics, NAS infrastructure, data, 
spatial/temporal flight mapping; for investment alternatives analysis inputs 
on conflict potential, sector loading, workload and resource 
demand/capacity imbalances. 

4 . Outputs 

NARIM output metrics vary depending upon the particular analysis being 
performed. They include: for operational analysis outputs about sector 
loading, travel times, assigned delays, en route/amval/departure delays, 
workload, conflict potential and conflict analysis; for architecture and 
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infrastructure analysis outputs on resource demand/capacity imbalances; for 
investment alternatives analysis outputs on numerous metrics such as cost 
by airline/airframe, time savings, fuel savings, direct operating costs, levels 
of safety, controller workload, etc. 

5 . Major Assumptions 

NARIM analyses will be drawing on the capabilities of a large set of 
constituent models. Therefore, the major assumptions made in each 
analysis will reflect the assumptions inherent in the particular set of models 
(e.g., RAMS, TAAM, etc.) which will be utilized in each specific case. 

6 . Computational Characteristics 

The NARIM prototype currently consists of three independent, stand-alone 
software elements. Of these, the most mature is the operational modeling 
element, consisting of several stand-alone software modules integrated 
through data. These software modules reside on a workstation running the 
UNIX OS and are written in C and C++. NASSIM, the prototype 
architecture/infrastructure model resides on a Power PC-based Macintosh 
computer and is written in Extend™, a COTS simulation development 
environment. The IRSM methodology tool is hosted on a Pentium-based 
PC running the UNIX OS and is developed in XRT-3D 

7 . Modularity and Flexibility 

The design approach undertaken for the NARIM prototype development 
was to provide reusable software components based predominately upon 
ASD analysis tools; existing and on-going research initiatives sponsored by 
ASD. In addition to minimizing prototype development time and risk, this 
design approach will ensure that NARIM is modular and extendible, 
providing long term benefit to the FAA and the NASA through software 
reuse as well as provide immediate utility to both organizations near-term 
analysis needs. The long-term result of this approach will be development 
of an analysis framework in which individual components may be 
configured to support timely multi-dimensional analysis of a multitude of 
diverse aviation issues. 


8 . Status of Model 

The model has completed the first of three planned builds. At this time, 
NARIM documentation is not sufficient to support replication of the model 
and distribution to other organizations. Since integration within the current 
prototype is through data, current users of NARIM are restricted to software 
developers. 

9. Extent of Model Validation 

Since NARIM input consists of actual FAA operational data (such as 
ACES, ETMS, NAS subsystem performance characteristics ) the input data 
sources should require no further validation. The model components are 
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being validated as a part of the ongoing analyses being performed as a part 
of the NARIM rapid prototyping effort. 


10. Principal Applications 

The principal applications of NARIM are associated with the modeling and 
analysis of airspace and aviation concepts for future development. NARIM 
is being developed to assist the FAA and the NASA in the research and 
investment allocation process. 

11. Availability 

Upon request to Dr. Mark Rodgers, FAA/ASD-430, Federal Aviation 
Administration, 800 Independence Ave., SW, Washington, DC 20024. 
Phone: (202) 358-5372. Email: mark.rodgers@faa.dot.gov 


12. Information for Model Evaluation 

NARIM Needs Analysis and Operational Concept Report, April 1996 


16. Summary Evaluation 

The purpose of the National Airspace Resource Investment Model 
(NARIM) is to provide NASA and the FAA with the modeling and analysis 
capability to analyze airspace concepts for future development. The system 
is being developed to also provide a National Airspace System (NAS) 
perspective to the research and investment allocation process. In providing 
this perspective, NARIM is to include the modeling and analysis of current 
and potential operations, the engineering impacts of future systems and the 
ability to trade requirements within a system and across system and 
procedural investment alternatives. 

Due to lack of experience to date it is premature to attempt any evaluation of 
NARIM’s strengths and weaknesses, even with regard to its first “build”. 
Undoubtedly, NARIM, as a concept, represents one of the most ambitious 
ATM model development projects ever undertaken. 
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6.0 NOISE Models 


6.1 Review of Noise Models 

This brief section provides individual reviews for two noise models, INM 
(The Integrated Noise Model) and NOISIM, a model developed very 
recently at MIT for the purpose of providing highly detailed analyses of 
single noise-generating events due to arrival or departure of an aircraft at an 
airport. These two models are outside the main scope of this study and the 
two reviews below have been prepared only for the sake of providing 
information to potential noise model users. 

6.2 Reviews 

6.2.1 Integrated Noise Model (INM), Version 5.0 (FAA) 

(Last update: 8/29/96 JKK) 

1. Primary Model Category 

Modeling and Display of Aircraft Community Noise Impact. 

2. Summary 

INM is an empirical tool used to calculate the noise impact around airports. 
The noise levels are based on a series of stored noise profiles of different 
aircraft under different flight conditions such as weight and trip length. The 
model has recently been enhanced (Version 5.0) to include a number of new 
capabilities. 

3. Input Requirements 

Requires an aircraft flight profile, including aircraft type, flight plan, and 
trip length (gross weight). Data may be entered using a graphical user 
interface using Windows. Geographical Information System (GIS) overlays 
can be used to show impact on population and topography. The model 
includes navigational aid data for the entire U.S. and can also incorporate 
ARTS radar data to examine actual trajectories. Official Airline Guide 
(OAG) data can also be used to examine traffic schedules and fleet mixes. 

4. Outputs 

A Graphical User Interface is also used for analysis of the results. INM 
displays the community noise impact as a series of noise contours in Noise 
Exposure Forecast (NEF), Equivalent Sound Level (Leq), Day-Night 
Average Sound Level (Ldn), and Time Above a specified threshold of A- 
Weighted Sound (TA). The model calculates the total area exposed to 
different noise levels, and the population exposed to different noise levels. 
A differencing feature is included to allow the comparison of two different 
operating conditions on noise impact. 
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5. Major Assumptions 

The trajectory of the aircraft can be modeled as a series of straight and 
constant-radius curved segments or can be specified using actual ARTS data 
or through OAG schedules. Noise information is stored as intensity directly 
below the path of the aircraft. Sideline noise measurements are calculated 
using a lateral attenuation factor that is a function of the aircraft's height and 
azimuth above the ground. The model can be used to examine single or 
multiple events, and can include lateral dispersion of flight tracks. Wind is 
not included as a parameter. 

6. Computational Characteristics 

Code exists for Windows NT (recommended) and Windows V3.1 for PCs. 
Minimum specifications are: 486DX 66MHz processor, Microsoft 
Windows NT (V3.5) with 35 MB RAM or Windows V3.1 with 16 MB 
RAM, 640x480 16 color VGA display, mouse input device, 3.5" 1.44 MB 
floppy disk drive, 300 MB hard drive (INM requires 20 MB, each study 
requires 1-30 MB), CD-ROM drive for terrain and census data processing 
(optional). 

7. Modularity and Flexibility 

INM is a stand-alone analysis tool and would not be easily ported or 
incorporated in a larger software package. 

8. Status 

The model is the FAA standard for calculating aircraft noise impact. 

9. Extent of Model Verification 

The empirical data used in the model has been verified through an extensive 
testing program. 

10. Principal Applications 

Calculation of the noise impact (in terms of area and population) for a single 
aircraft for a single event or a mix of aircraft over an extended period. 
Includes lateral dispersion of flight tracks, flexible aircraft profile 
generation, graphical track construction, and expanded visual analysis. 

11. Availability 

Available for $250 from the FAA. Contact: John Guiding, INM 5.0 
Program Manager, (202)-267-3654. 

12. Information for Model Evaluation 

User's Guide for INM (V3.0); V 5.0 press release; communication with 
Donna Warren, FAA. 
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13. Summary Evaluation 

INM is the FAA standard noise prediction tool. It assumes that aircraft will 
fly trajectories that can deviate from specified flight plans or can use ARTS 
trajectory data. It is limited in its ability to predict the variability in noise 
impact that could occur due to wind conditions, but is flexible in terms of 
analyzing operating procedures and fleet mixes. INM has improved 
graphical interfaces for both data entry and visual analysis of the results. 

6.2.2 NOISIM 

(Last update: 5/13/96 JKK) 

1. Primary Model Category 

Modeling and Display of Aircraft Community Noise Impact. 

2. Summary 

NOISIM is a real-time aircraft simulator with the ability to model and 
display the community noise impact of a specific trajectory that is flown. 
The model implicitly includes any aircraft-specific constraints and also 
includes the effect of wind or other atmospheric conditions on aircraft 
performance and noise propagation. 

3. Input Requirements 

NOISIM requires a pre-programmed flight plan or real-time procedure entry 
through a control display unit, mode control panel, keyboard, or manual 
stick inputs. A Graphical User Interface is used to plot and calculate noise 
impact. Right plans can be pre-programmed using a text input file. Wind 
conditions can also be prescribed in a text input file. Changes in wind 
conditions can be scripted (e.g., to simulate windshear events). 

4. Outputs 

NOISIM displays the community noise impact as a series of noise contours 
in A-Weight Sound Pressure Level (dBA) or Sound Exposure Level (SEL). 
These contours are overlaid on a map derived from USGS hydrography and 
land use data. The model calculates the total area exposed to different noise 
levels, the land area exposed to different noise levels, and the population 
exposed to different noise levels. Other derived metrics such as the 
Equivalent Sound Level (Leq) and Time Above a specified threshold of A- 
Weighted Sound (TA) can be calculated. 

5. Major Assumptions 

The aircraft performance and engine parameters at each iteration step are 
calculated as if the engine is at steady state. 
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6. Computational Characteristics 

Code exists (written in C). Software has been developed for Silicon 
Graphics platforms. Documentation quality is currently in draft for the 
prototype version. Calculation of the noise impact takes 15-20 minutes of 
post processing computation. 

7. Modularity and Flexibility 

The simulator allows rapid prototyping of different cockpit display, 
navigation systems, aircraft parameters, and engine parameters. It is 
currently configured with 737 performance and engine parameters, and 747- 
400 instrumentation. Modifications to the dynamic model may involve 
significant recoding. Topographical data for the Boston metropolitan area is 
currently included to determine land area noise impact. Noise calculation 
routines are modularized and can be separated from the aircraft simulation. 

8. Status 

The model is intended as an experimental tool, is a first prototype, and is 
not mature. An extensive graphical user interface is in place and is easy to 
use for the display and calculation of noise impact. 

9. Extent of Model Verification 

In a series of simulations designed to mimic the radar trajectory of a 737 
operating out of Boston Logan Airport, the noise simulations agree to 
within 2 dBA with recorded data from noise monitoring stations around the 
airport. 

10. Principal Applications 

Investigation of the trades between noise impact and aircraft performance. 
Development of prototype noise abatement procedures. 

11. Availability 

Contact: John-Paul Clarke, MIT, (617) 253-7748, johnpaul@mit.edu, or 
Prof. R. John Hansman, MIT, (617) 253-2271, rjhans@mit.edu 

12. Information for Model Evaluation 

Summary is based on a review by the author of NOISIM. No 
documentation is currendy available. 

13. Summary Evaluation 

NOISIM is a prototype version of an all-in-one aircraft noise simulator 
developed to investigate the trades between noise impact and aircraft 
performance, and evaluate prototype noise abatement procedures. The 
model has realistic flight dynamics and implicitly includes the performance 
constraints which limit the maneuvers that may be performed in a noise 
abatement procedure. It also provides researchers with a tool to determine 
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how piloted aircraft flight procedures affect the community noise impact. 
NOISIM uses actual piloted flight data to determine noise impact, rather 
than an assumed trajectory that is followed perfectly. Thus, NOISIM 
appears to be better able to show expected variations in noise impact due to 
aircraft tracking performance or wind conditions than the Integrated Noise 
Model (INM). 
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7. CONCLUSIONS AND RECOMMENDATIONS 


We present next the principal conclusions of this study and a related number 
of action recommendations. These recommendations are in addition to the 
numerous recommendations that have already been made in connection with 
improvements and further model development in the areas of capacity and 
delay modeling (Section 2), conflict detection and resolution (Section 3), 
humans / automation models (Section 4) and cost/benefit analysis (Section 
5). Section 7.1 summarizes the overall conclusions with regard to the state- 
of-the-art in the various categories of ATM and airport modeling. Section 
7.2 draws from these conclusions to articulate some overall policy 
guidelines that might inform future FAA and NASA policies regarding ATM 
and airport development. Finally, Section 7.7 presents an additional set of 
recommendations that span the specific categories of models discussed in 
Sections 2-6. 

7.1 General Findings 

One fundamental conclusion of our review is that the state-of-the-art varies 
considerably across the various categories of airspace and airport modeling. 
A ranking of the categories, from most advanced to least, would be as 
follows: 

1. Capacity and delay models 

2. Conflict generation, detection and resolution models. 

3. Human factors and automation models. 

4. Cost/benefit models. 

5. Models of strategies and behavior of airlines (airline operations 

centers) and of other users vis-a-vis ATM. 

As this ranking indicates, capacity and delay models are, in the view of the 
study team, the most advanced, in terms of being able to meet user needs. 
After more than three decades of work the “physical principles” of air traffic 
flows, capacity and delays are reasonably well understood. The family of 
existing models in this area has the ability, with proper use, to provide 
reasonably good estimates of capacities and delays for individual elements 
and even for groups of elements of the ATM system. Moreover, different 
models address these issues at different levels of detail (low, intermediate 
and high) and thus make it possible for informed users to select a model(s), 
and corresponding level of detail, most appropriate to their needs. 

However, some serious deficiencies still remain. The best existing capacity 
and delay models still suffer -different models to different degrees- in 
several fundamental respects that were discussed in Section 2. These 
deficiencies can be classified into a small number categories: lack of some 
essential features (e.g., stochasticity); lack of flexibility (e.g., a node-link 
structure); lack of mutual compatibility; poor user interfaces; and costly and 
time-consuming training, learning and input/experiment preparation 
requirements. 
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Conflict generation, detection and resolution models have attracted much 
attention in recent years, especially in connection with proposed new ATM 
concepts, such as Free Flight. Understanding of the fundamental issues in 
this area has improved considerably as a result and a number of models 
(Section 3) have been or are being developed that provide significant 
capabilities in this respect. However, in the view of the study team, no 
single existing model provides enough flexibility and capability to perform a 
complete, in-depth study of conflict detection and resolution. Each existing 
model lacks some or many of the features necessary for such a task. 

The area of fast-time modeling of humans and automation in ATM (Section 
4) is still in its early stages of development. We could identify only one 
general-purpose model (MIDAS) and very few special-purpose ones. 
While these provide a good starting point, much remains to be done. Many 
of the basic principles and issues in this area are not yet fully understood at 
the conceptual level. Given the immense importance of human 
factors/automation in the design and operation of any of the proposed 
advanced ATM concepts, this category of modeling deserves urgent 
attention and investment of adequate resources by the various national and 
international civil aviation authorities and organizations. 

The state-of-the-art in estimating costs and benefits (Section 5) associated 
with advanced ATM concepts, such as Free Flight, is rather primitive at this 
time. Most of the available models deal with four metrics of ATM 
performance: capacity, delay, fuel consumption and workload (as inferred, 
for example, by the number of conflicts that must be resolved). But many 
of the potential benefits of proposed advanced ATM concepts, such as 
“safety”, “increased operating flexibility for airspace users”, “lower costs 
for ATM system operators” or “increased access to airports due to better 
navigation capabilities” are not captured in any way by available models. 
Moreover, our ability to estimate in economic terms the value of many of 
these costs and benefits still leaves much to be desired. Much basic research 
is needed in all these respects. 

Only one general-purpose model, ACIM, in this area has (very recently) 
reached an adequate level of maturity. ACIM is a valuable tool for 
projecting the impacts of future changes in ATM- and airport-related costs 
on air transportation demand and airline growth and fleets. However, 
ACIM does not, of itself, estimate these airport/ATM costs, but must rely 
on other models to do so. A far more ambitious effort to develop an 
integrated suite of models, NARIM, that would guide ATM-related 
investments and support cost-benefit analyses has been launched by the 
FAA, but it is too early to judge its level —or, even, its prospects— of 
success. 

Finally, our examination of modeling needs for the evaluation of partially 
decentralized ATM concepts, such as Free Right, has made clear the almost 
complete absence of any models that would assist ATM planners to predict 
airline and other airspace user strategies and behavior in such an 
environment. Free Flight and related concepts are characterized by the 
transfer of some or many decision-making responsibilities to airspace users 
and provide these users with increased latitude in planning and performing 
flights. Understanding how users, especially airline operations centers, 
would operate under such circumstances (including arrival and departure 
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slot utilization, allocation of expected delays between delays taken on the 
ground before departure and delays taken in the air, “gaming” to gain 
advantage over competitors, etc., etc.) is an essential element of our ability 
to assess and evaluate these new ATM concepts. The development of 
models that would make such understanding possible represents an entirely 
new area of basic research that has, all of a sudden, assumed major 
importance. 


7.2 Strategic Guidelines for Future Work 

The findings described in the last section and in Sections 2-6 have important 
strategic implications regarding future work on airport and ATM modeling. 
We present below a set of proposed policy guidelines to assist NASA and 
the FAA in this respect: 

1. Not only strong enhancements to existing models, but also extensive 
new modeling capabilities will be needed in the short, medium and long 
term, to determine the feasibility and evaluate proposed advanced ATM 
concepts, such as Free Flight. In several cases, these new capabilities must 
go well beyond anything that exists today and will require work on 
understanding basic principles before modeling per se can begin. In view 
of the fact that assessment and evaluation of advanced ATM concepts has 
already started at the FAA and under NASA s AATT concept, the 
development of the models must be undertaken immediately and in parallel. 
This is an urgent requirement: assessment and evaluation simply cannot be 
done in a credible way without the support of adequate and credible models. 

2. The FAA and NASA should draw up a detailed plan for supporting 
model development and experimentation. This plan should be dynamic, 
i.e., it should not be “cast in concrete” so it can be revised appropriately 
over time to take into consideration successes and failures along the way. 
Adequate funding for such a model development program should be 
provided for. A conservative guess is that an amount of at least $10 million 
per year over several years would be necessary to support a credible 
program of development, validation and experimentation with fast-time 
models. (This is in addition to the significant investments currently being 
made by both NASA and FAA in real-time, human-in-the-loop facilities.) 

3. Drawing up such a program would be greatly assisted by the existence 
of a few well-defined strawman architecture(s) of advanced ATM concepts, 
such as Free Flight. Such architectures are currently in the process of being 
developed. They would be very useful in specifying the kinds of 
capabilities that existing, enhanced and newly-developed models should 
have and in setting priorities and allocating funding among alternative 
model-development paths. 

4. Model development can be facilitated further through specification of 
model requirements with broad user participation. A good example of this 
approach is a recently formed, broadly-participatory group in Europe, 
whose objective is to develop a detailed set of specifications for future 
airport/terminal area modeling. 
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5. In allocating resources for future model improvement and new model 
development, it is important to recognize the need for: 

(a) Modeling the ATM and airport systems at several different levels 
of and/or accuracy (macroscopic, mesoscopic, microscopic, in the 
terminology used in this report); the tendency to ovremphasize microscopic 
models should be resisted. 

(b) Databases and generic “utility” modules (see Section 7.5 below) 
that can be used to support many models in any given category. 

6. It is important to recognize the synergisms and trade-offs between fast- 
time models, which are the subject of this report, and real-time, human-in- 
the-loop ones. It is, of course, true that many ATM concepts and changes 
cannot be validated without the eventual use of the latter. However, human- 
in-the-loop experiments are time-consuming and costly and the associated 
facilities very expensive. Fast-time models can be very effective as "filters 
for eliminating large numbers of proposed alternatives before subjecting the 
remaining few to real-time tests. There are also certain types of issues 
(e.g., ones exploring capacity, delay and workload on a broader, sometimes 
system-wide basis) that simply cannot be investigated without the use of 
fast-time models. 

7. Existing ATM and airport models to date have been primarily developed 
by ATM and airport specialists for whom software development has been a 
secondary consideration. As a result, the usability, robustness and user 
interfaces of many existing models are severely deficient. Much improved 
software engineering practices should be expected and required be in the 
future. 

8. Along similar lines, existing airport and ATM models are all essentially 
of the “passive” and “what if...” type: a hypothetical situation is posited 
and the model performs a simulation or similar analysis and provides a set 
of results. The model does not provide a diagnosis of any problems about 
the situation that has been analyzed or simulated —such as identifying the 
“bottlenecks” at an airport- nor can it suggest alternatives for solving such 
problems (i.e., the model does not “optimize” in any sense). However, it is 
now technically feasible to add some such diagnostic and optimization 
capabilities to several types of models. This important type of improvement 
should be encouraged and explored. 

9. Finally, in supporting future model development and allocating related 

resources, it is important to seek a proper balance between two fundamental 
strategies: (a) building new or improved models that address in a 

comprehensive manner specific domains (e.g., a better future model of all 
aspects of airport operations); and (b) developing “suites” or “toolkits” (in 
the NARIM or ASAC mode) of compatible models that can serve as 
"building blocks" to be assembled and configured, as needed, in addressing 
issues at hand. The viability and attractiveness of the second strategy has 
been greatly strengthened recently by the emergence of distributed 
simulation technologies. 
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7.3 Specific Recommended Actions 


The principal recommendations of this study are that: 

1. A model improvement and development program, consistent 
with the policy guidelines provided in Section 7.2 above, be undertaken by 
NASA and/or the FA A. 

2. The numerous specific recommendations (about 25) made in 
Sections 2.1, 3.1, 4.1 and 5.1 be reviewed carefully as potential tasks to be 
carried out in connection with the recommended model improvement and 
development program. 

In addition, the following potential areas of activity, which are not 
specific to any particular category of models, should be considered in 
connection with the proposed program: 

(a) Better information for prospective ATM and airport model users: 
The most common and costly mistake of model users today is the selection 
of models w'hich are not appropriate for their needs. An example, might be 
the use of a highly-detailed model, like SIMMOD or TAAM, to identify the 
time w'hen significant expansion of an airport's capacity will be necessary. 
This is a "macroscopic" policy question which typically looks 10-20 years 
into the future. It should be answered with the help of an approximate, fast 
and easy-to-use model, not one that requires a detailed layout of the airport, 
the construction of highly detailed scenarios, which are subject to great 
uncertainty, and a (totally speculative) flight-by-flight demand schedule for 
the distant future. Similar examples abound. 

Such mistakes are due to lack of information on the part of potential 
model users (including large government organizations) about what models 
are available (typically the potential user is aware of only a handful) and to 
lack of appreciation of the fact that the best model to use depends on what 
question is being addressed. There is therefore a clear need to educate 
potential users of ATM and airport models about: 

(i) model availability; 

(ii) model characteristics, especially their fundamental assumptions, 
limitations and level of detail; 

(iii) explicit and hidden costs (e.g., learning costs, limited technical 
support) associated with model use; and 

(iv) the proper criteria for model evaluation and selection. 

The research reported here is a step in this direction. Other helpful 
information is available in a number of Web sites referenced in Appendix C. 

(b) Integration of existing models: This point has been raised on 
several occasions in this report, but is worth repeating, because of its 
importance. Possibly the one most striking observation to emerge from this 
study concerns the lack of any semblance of compatibility among the many 
models reviewed. As a rule, existing models have been developed 
independently of one another, have different data needs and input and 
output formats and sometimes contain conflicting assumptions. This makes 
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it extremely difficult to conduct any systemic studies that examine at the 
same level of depth different elements of the ATM system or address a 
particular question at progressively greater levels of detail. 

Yet, there are many cases in which it would not be particularly 
difficult to develop interfaces between existing models that would make it 
possible to move seamlessly from model to model and obtain an overall 
capability that is "greater than the sum of its parts". Several specific 
examples have been provided at various points in this document. 
Eventually such efforts could lead to the assembly of compatible "toolkits" 
of models such as the ones described in earlier sections. A major 
development of the last couple of years has indeed been the initiation of a 
few projects along the lines outlined above. For example, the TAPE project 
in Europe is attempting to integrate several airside (runways, taxiways, 
apron) and landside (passenger terminal) models of airport operations, so 
that the user can observe the effects of proposed airside changes or of 
airside congestion on passenger terminal operations and vice versa. 
Similarly, two other ongoing projects in Europe are developing interfaces 
between RAMS and, respectively, SIMMOD and PUMA. The ASAC and 
NARIM projects in the United States have even more ambitious long-term 
objectives concerning the development of compatible model suites. These 
efforts, we believe, reflect the growing international recognition of the need 
to improve model integration. 

(c) "Utilities" and databases: In addition to developing better ATM 
and airport models, it is also very important to improve the supporting 
utilities and databases which are often required by these models in a wide 
variety of contexts. We offer several examples below. 

There is a major requirement for "utility" programs that would 
facilitate the generation of (i) hypothetical demand schedules for ATM and 
airport facilities and (ii) representative weather scenarios. With respect to 
(i), practically all existing capacity and delay models require detailed, flight- 
by-flight schedule of demand over the course of a day of operations. In 
particular, network models such as NASPAC, AND and ASCENT that are 
concerned with operations over an entire system of airports and/or en route 
sectors also require flight connections, i.e., complete itineraries that indicate 
the route that each aircraft of an airline will execute on any particular day. 
Obviously, such detailed demand scenarios, especially the ones requiring 
complete aircraft itineraries, are not available for the future and have to be 
developed for use with network models. To our knowledge, only two such 
detailed demand generators are currently available. One is the Pseudo - 
Official Airline Guide Generator (POAGG) that has been developed at the 
Draper Laboratory to support ASCENT. POAGG uses a combination of 
heuristics and mathematical programming to create reasonably realistic flight 
schedules that satisfy user-specified parameters including: the number and 
houtrly distribution of arrivals at each airport in a network; the percentage of 
flights that connect to each of the other airports in the network; the presence, 
if any, of shuttle flights between pairs of airports in the networks; and the 
presence, if any, of "banks" of flights at the hub airports in the network. 
The other such demand generator, with apparendy similar characteristics, 
has been developed at MITRE CAASD for NASPAC. There is 
considerably more work that can be done to improve the state-of-the-art in 
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this area, and resulting programs, once tested and validated, should be 
disseminated widely, so they can support a wide range of models. 

A similar need exists for "utilities" which will provide weather 
scenarios for use with a large variety of ATM and airport models. These 
include the generation of: simulated weather front and winds aloft scenarios 
for use with airspace models; visibility, ceiling, wind and precipitation 
scenarios for airports; and, most difficult, regional models that generate 
weather scenarios for several locations simultaneously and capture 
realistically the potentially strong correlation between weather conditions at 
geographically proximate airports (e.g., Washington, New York and 
Boston). The state-of-the-art is not particularly advanced in this respect, but 
a number of approaches have started to emerge in recent years. Examples 
include Markovian and semi-Markovian models to generate weather 
scenarios at individual airports and the U.S. Air Force's Sawtooth Weather 
Model for generating regional weather profiles. Considerable additional 
resources w'ould need to be invested in this area. 

Turning to databases, it is clear that there exists, once again an acute 
need for improvement. The ATM research and development community 
would benefit greatly from an effort aimed at assembling and maintaining a 
set of databases that would facilitate future modeling and simulation 
experiments and, equally important, make it possible to compare the results 
obtained from different models and approaches. Four obviously needed 
types of databases are: 

(i) "Standard day" scenarios for specific locations (e.g., terminal 
areas) or regions (e.g., Northeast United States, Western Europe) that 
include detailed information on traffic demand, weather, capacities 
achieved, delays, etc. on these days. 

(ii) Computer-coded airport layouts and airspace configurations, 
obtained from previously performed studies. 

(iii) Standardized set of performance characteristics for a large 
number of commercial and (possibly also) general aviation aircraft types. 

(iv) Inventory of airline costs, fleet composition, financial 
performance, demand, traffic growth, etc. 

Much already exists in both areas (i) and (ii). For example, the 
FAA has used SIMMOD to simulate large portions of the U.S. airspace 
and, in the process, has developed detailed network representations of this 
airspace, some reportedly involving as many as 20,000 links. (More 
obviously, numerous airports in the U.S., Europe, Asia and Australia have 
been simulated with SIMMOD, The Airport Machine and TAAM, with 
much effort expended on coding the layouts of these airports for use with 
these models.) However, no organization to date has assumed or been 
assigned the responsibility for maintaining these data sets and making them 
available to other potential users. 

In areas (iii) and (iv) the situation is more promising because of the 
grow'ing international use of BADA as a source of commercial aircraft 
performance data and of the recently implemented LMI Air Carrier 
Investment Model (ACEM) as the source of airline-related data. Much, 
however, still remains to be done in both respects. 
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(d) Models of Airline Operations Centers fAOC) and of their 
interactions with ATM: As observed in Section 7.1, our examinadon of 
modeling needs for the evaluation of partially decentralized ATM concepts, 
such as Free Flight, has underscored the almost complete absence of any 
models that would assist ATM planners to predict airline and other airspace 
user strategies and behavior in such an environment. Yet, understanding 
how AOCs will interact with ATM in a more decentralized decision-making 
environment is essential to evaluating advanced ATM concepts of the future. 
Thus, the development of models that would make such understanding 
possible represents an important new area of basic research. We strongly 
recommend that such work be initiated immediately, in close collaboration 
with the airlines. Many dicussions and contacts have made it clear that 
many AOC professionals already recognize the need for such work and 
would offer valuable support along these lines. 
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Appendix A: Free Flight Case Study 


1. The Issues 

This is a report on the first case study carried out under the MIT 
Model Review and Evaluation project undertaken in connection with 
NASA’s AATT Program. This first case study is centered around the Free 
Flight concept. In particular we are concerned with identifying and 
describing the kinds of modeling capabilities that one would need in order to 
analyze and evaluate the Free Flight concept. 

Based on a critical review of available materials prepared in October 
1995 by the Steering Committee of RTCA Task Force 3 on Free Flight 
Implementation., it is clear that the Free Right concept is still in its 
formative stages. The driving motivation behind it is the desire to remove, 
to the greatest extent possible, the constraints currently imposed by ATM on 
flying under IFR, so that aircraft can take maximum advantage of rapidly 
improving aircraft- based capabilities. This calls for some fundamental re- 
thinking of the basic premises of the ATM system. 

It is far from clear, however, that Free Right can work in the 
presence of some of the severe capacity limitations that the ATM system is 
faced with, especially in major terminal areas and in less than ideal weather 
conditions. The extent to which Free Flight can be practiced at times when 
airport acceptance rates require the imposition of some controls on the flows 
of traffic remains an open question. A major restructuring of air traffic flow 
management might be called for. 

On this crucial point, current thinking is to try to replace today’s 
“controlled time of departure” (i.e., specifying when a flight operating 
under flow management restrictions will take off) by a “required time of 
arrival”, RTA, which will specify when a flight has to arrive at a specific 
location. This location could be at a fix just outside the terminal area of the 
airport of destination or at some other point which, under circumstances of 
major congestion, could be several hundreds of miles away from the airport 
of destination. The idea, of course, is that each flight would determine for 
itself an “optimal” (according to some criterion) strategy (i.e., a 4-D 
trajectory) for getting at the specified point at the specified time. Each flight 
would use a “user preferred route” (i.e., a Free Right path) to get from the 
airport of origin -or, from the boundary of the terminal area of origin - to 
the location at which the specified RTA would apply. Thus, this approach 
would do away with the current use of en route “miles in trail” -or “minutes 
in trail”- separations along standardized routes. However, it is still unclear 
how the “boundary conditions” imposed by congested terminal areas might 
impact (i) the extent to which optimal point-to-point trajectories could be 
utilized en route and (ii) the number and complexity of the conflicts between 
flight trajectories that would have to be detected and resolved in the aispace 
where Free Flight would be available. 

A critical related question concerns the robustness of the traffic flow 
management scheme outlined above. The transition from Free Flight to a 
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“flow managed” regime in and near terminal areas would have to be 
accomplished smoothly, routinely and always safely in the presence of 
uncertainty. This uncertainty derives from at least three causes: (a) the 
variability in airport capacities due to fluctuations in traffic mix and attendant 
spacing between successive arrivals, as well as the mix and sequencing of 
arrivals and departures; (b) unexpected changes in airport acceptance rates 
due to weather variability, wind shifts, changes in runway configurations in 
use; and (c) short-term differences between predicted and actual airport 
demand, due to unanticipated flights ("pop-ups"), cancellations or 
diversions of flights, etc. 

In summary, determining the workability of Free Flight requires a 
very extensive amount of analysis. This motivates the question we are 
addressing under this case study which can now be stated in the following 
terms: "Given Free Flight as a 'generic' concept, what kinds of models and 
tools would be necessary to assess its safety-related characteristics as well 
as its costs and benefits to ATM users (including passengers) and operators 
(including all those who pay for the ATM system)?" Fortunately, this 
question can be addressed without having to wait for the full definition of a 
future ATM system based on the Free Flight concept -a milestone which 
may still be some time away. 

To make the task more manageable, it was decided to decompose the 
above question into four simpler parts, as follows: 

(1) Optimal flight trajectories and planning: Assume, first, that 

there is only a single aircraft in the world. What kinds of 
models/methodologies would be needed for computing a 4-D "optimal" 
flight trajectory for that aircraft from origin to destination? (We leave 
unspecified here the definition of "optimal" and we presume that the 
question needs to be addressed under a variety of assumptions regarding 
aircraft capabilities, available information about weather/winds, frequency 
of information updates, etc.) 

(2) Conflict frequency, detection and resolution: Assume next that 
each aircraft would fly independently its own optimal 4D trajectory and that 
there are no capacity limitations at airports. What kinds of models would be 
needed to evaluate the statistics describing frequency of conflicts and the 
associated levels of system integrity that would be generated by some given 
ensemble of aircraft, performing a given schedule of flights with a specified 
temporal and spatial distribution? (A “conflict” here is defined by a measure 
of spatial proximity and by some conflict geometry; “conflicts” may 
translate into “alerts”, pilot and ATC controller workload, etc.). It is also 
important to consider what kinds of models would be needed to design and 
evaluate conflict resolution systems that are used to separate aircraft once a 
conflict has been detected. For example, issues such as safety, false alarm 
rate, and the impact of conflict resolution on traffic flow will need to be 
evaluated. 

(3) Operation under traffic flow limitations: Assume next that Free 
Flight is possible en route (so that each aircraft can fly its own preferred 
route between two en route points) but airport capacities impose “boundary 
conditions” on acceptance rates into terminal areas. What kinds of models 
would be necessary to investigate what would happen at the boundary 
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between airspace in which Free Flight can be accommodated and airspace in 
which it cannot due to capacity constraints? How can one analyze the 
manner in which the effects of such boundary conditions would 
spread/propagate through the rest of the ATM system? Finally, what are the 
implications for how the traffic flow management (TFM) system should be 
configured to operate in a way compatible with and supportive of Free 
Flight? 


(4) Benefits and costs: Assume finally that Free Right can still be 
accommodated in parts of the airspace, despite the presence of such 
boundary conditions and capacity limitations. What kinds of models would 
be needed to estimate the associated incremental costs and benefits? 

A common underlying issue in the cases of (2) and (3) is that the 
necessary models should also be capable of providing measures of 
robustness (e.g., what is the range and probability distribution of the 
number of conflicts? what is the susceptibility to various types of 
uncertainty of the transitioning from Free Flight to terminal area flight? 
etc.). 


The principal findings on each of the items (1) - (4) above are now 
outlined. 
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2. Models for Generating Optimal Trajectories 

The Free Flight Environment assumes that user-preferred flight 
plans would be used by airlines and pilots whenever possible, and that these 
flight plans could be amended in flight. To simulate a Free Flight 
environment in a realistic manner, it will be necessary to generate simulated 
airline flight plans which are reasonably representative of the optimized 
flight plans which are likely to be actually flown by airlines. Flight plan 
optimization requires a set of realistic objectives and constraints, as well as 
high-performance optimization algorithms. The optimization environment is 
summarized in Figure 1. 



Figure 1: User-preferred flight plan optimization environment 

The corresponding modeling needs can be identified by a detailed 
functional analysis of the flight plan optimization process in an airline setup. 
In the case of general aviation, most of the tasks which will be decribed are 
performed by the pilots. 

Functional analysis of optimal flight plan generation 

The following functional analysis is an extrapolation from current 
airline practice. It outlines what an optimization process is likely to look like 
under certain assumptions. 

The optimal flight plan generation process can be divided into two 
subprocesses: 

- strategic flight planning 

- tactical flight plan amendments 
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The strategic plan attempts to optimize over the entire flight while the 
tactical plan responds to short-term unanticipated changes in the aircraft's 
situation. 

Strategic flight planning 

The strategic planning subprocess is presented in Figure 2. It is 
centered on the Airline Operating Center (AOC) dispatcher. It may run 
several times during a flight as new information becomes available. 

The subprocess is divided into an inner loop and an outer loop. The 
inner loop is essentially concerned with ensuring flight safety and passenger 
comfort. A weather specialist translates weather forecasts and pilot reports 
(PIREPs) into geometric 4D path constraints and runs the Trajectory 
Optimization algorithm. This algorithm computes the minimum fuel 
trajectory, taking into account these geometric constraints and the following 
parameters: 

- the aircraft characteristics: drag polar, engine thrust, fuel capacity and fuel 
consumption tables for the given payload; 

- the aircraft ETOPS certification; 

- the constraints defined by the dispatcher who requested the computation. 

• lower and upper bounds for the Required Time of Arrival or RTA (at a fix 
or at the destination airport); 

• 4D geometric constraints to avoid congested airspace which could cause 
delays. 

- the status or level of activity of the Special Use Airspace (SUA); 

- the forecast winds; 

- the aircraft's current state (position, velocity, etc.). 

Note that the first two remain constant during a given flight, 
whereas the others are updated during the flight. 

The optimization algorithm also provides the fuel burn for the 
computed trajectory, and its sensitivity to the geometric constraints. Thus 
the weather specialist can get an indication of the impact of the geometric 
constraints he or she defined on the fuel bum of the flight, and modify them 
if appropriate. Once a route is chosen, the inner loop sends to the 
dispatcher 
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Figure 2: Flight plan optimization: Strategic Level. 

the trajectory, the corresponding fuel bum and the sensitivity of this fuel 
burn to the above parameters. 

The objective of the outer loop is to minimize the total cost 
associated with the flight. The dispatcher takes into account airline 
parameters such as: 

- crew scheduling requirements; 

- crew and scheduled maintenance costs per hour of flight; 
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- fuel price; 

- published airline schedules; 

- expected delays at the destination airport; 

- gate availability at the destination airport; 

- connecting flights; 

Note that the first three remain constant during a given flight, 
whereas the four others should be updated in flight. The dispatcher also 
defines 4D path constraints to avoid congested airspace which could cause 
delays. Then the inner loop is called to check the minimum fuel bum (and 
its sensitivities) for a given RTA interval. The dispatcher combines this 
information with the parameters listed above to choose the best RTA 
interval. The resulting flight plan is sent to the pilots via datalink. The pilots 
may accept the flight plan or request amendments. As new information on 
weather, winds, SUA status, etc. becomes available, the dispatcher runs the 
subprocess again to compute an updated flight plan which initiates at the 
current state of the aircraft. 

Tactical amendments 

The tactical flight plan amendment subprocess is presented in Figure 
3. It is centered on the pilots and is continually running during the flight. 

The flight crew is ultimately responsible for the safety of the flight. 
They receive Air Traffic Control (ATC) advisories and data from the on- 
board weather radar, and may encounter unreported turbulence. 

If they decide to deviate from the current flight plan, the size of the 
desired deviation is compared with some predefined 4D tactical limits. 

• if these limits are not exceeded, the pilots may proceed with the deviation 
without notifying the AOC, and then go back to the current flight plan as 
soon as possible. 

• if these limits are exceeded, the pilots report their intention to the AOC and 
ask for a revised flight plan. 

Thus the tactical limits may be seen as a 4D corridor around the 
current flight plan trajectory in which the pilots may maneuver the aircraft 
without notifying the AOC. In any case, the pilots send to the AOC repons 
on the turbulence they encountered or the weather pattern they decided to 
avoid. 
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Figure 3 : Flight plan optimization: tactical level 


Requirements for Models 

The functional diagrams in the preceding section serve to identify the 
models which would be needed to simulate the flight plan optimization 
process. In many instances models already exist and can be used with little 
or no modification. In other instances new models will be required. 

Existing data and models 

The following data and algorithms are readily accessible and could 
be adapted with limited effort: 

Aircraft characteristics 

Aircraft performance data are readily available from either aircraft 
manufacturer manuals or from databases accumulated by the airlines during 
actual operations. The effort to adapt the data for use in the present context 
should be minimal. 
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Scheduled maintenance costs and crew costs per flight hour 


Sufficiently accurate estimates of these costs should be available 
from airline databases. 

Minimum fuel optimization algorithm 

Numerous optimization algorithms (e.g., gradient methods) are 
currently in use and available for this need. These could be enhanced by 
combining them with stochastic schemes. A key element here will be to 
obtain efficient algorithms of varying degrees of specificity so that the 
model can be chosen to fit the need and excessive time and costs are not 
incurred. 

Models and algorithms still to be developed 

Models of human decision making will be needed to simulate the 
functions which will either be performed entirely by humans or will be only 
partially automated. As can be seen on the functional diagrams, these 
functions are: 

RTA selection 


A complex model is likely to be needed to appropriately replicate the 
complexity of airline scheduling and connecting flight constraints. A 
pragmatic approach would be to model RTA selection by a simple 
optimization based on readily accessible parameters and constraints such as: 


- approximate crew and maintenance costs per hour of flight; 

- fuel price; 

- number of gates at each airport; 

- published airline schedule. 

- minimum fuel bum for each RTA, as computed by the trajectory 
optimization algorithm. 

At that level of approximation, delays and missed connections could 
be assigned an arbitrary penalty. 

Weather-related decision making 

Currently, weather information and forecasts are given as text or 
maps obtained from various sources in various formats (surface reports, 
terminal area forecasts, SIGMETs, weather radar maps...). The weather 
specialists (or the general aviation pilots) integrate all this information and 
define constraints on the flight plan. This process involves experience and 
risk-taking. These knowledge-based decisions would have to be generated 
in the simulation. 
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Tactical weather avoidance maneuvers 

A model would be needed to simulate the behavior of pilots who 
encounter unexpected weather patterns or turbulence. This model could be 
based on empirical rules obtained from airline pilots. 

ATC advisories 

Models simulating the resolution of ATC conflicts are also required; 
these will be considered in the next section of this document. 

Other models that will be needed include: 

Simulated weatherAvind generation 

Weather and wind generation models would have to be developed 
for the simulation. They could be based on statistical data, wind and 
weather models currently used to produce forecasts, or simplified climate 
dynamics. In addition, this model would also generate corresponding 
weather forecasts to be used by the weather-related decision making model. 
These forecasts should include a realistic amount of uncertainty. 

Data availability and accuracy 

Airline Operation Centers do not always have the most current or 
accurate information, in particular regarding current SUA status and 
expected delays at the destination airport. To reflect this fact in the 
simulation, the data made available to the dispatcher should be a delayed 
and/or altered account of the real situation. These delays and alterations 
would have to be modeled. 


3. Conflict Models 


Given that more than one aircraft may be flying in local airspace, 
conflicts between aircraft may occur that necessitate replanning or 
maneuvering to maintain separation. The frequency of conflicts and their 
effects on aircraft must be examined because conflicts may impact the safety 
and efficiency of traffic flow. These analyses will require modeling and 
simulation tools which can be organized into several categories: 

(1) The density (spatial or temporal) of conflicts will be of interest as a 
predictor of the amount of additional intervention that will be required to 
maintain aircraft separation. Models of the traffic flow are needed to 
determine the frequency and form of conflicts (e.g., the geometry and 
number of aircraft involved in a conflict). 

(2) Conflict probe algorithms must be developed to alert controllers and/or 
pilots that a conflict exists. These probes will use sensor and datalinked 
information such as aircraft position and intended path to determine if 
intervention is required. Models are needed here to determine the 
effectiveness (e.g., false alarm rate) of conflict probe methods. 
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(3) Once a conflict is detected, some method of resolving the conflict is 
needed. Models are required to determine whether proposed resolution 
methods are effective in maintaining separation and to determine the impact 
of the conflict on the overall traffic flow. Additionally, human performance 
considerations during conflict resolution need to be modeled. 

These three categories of conflict models are shown in Figure 4. 
First, aircraft trajectories must be generated based on a model of assumed 
parameters such as aircraft type, routing logic, etc. A conflict detection 
model then determines which of these trajectories result in conflicts. A 
model for conflict resolution is also needed to obtain performance metrics 
such as accident rate based on some conflict resolution system. 



Performance Metrics 
Accidents / Incidents 


False Alarms 
Workload 


Figure 4: Basic Model Requirements 

A particular analysis may only consider the behavior of an ATM 
system within a single model category or between sets of models. For 
example, one model currently under development, is used primarily to 
generate aircraft trajectories [Roberts, et al. 1994], Other models take 
aircraft trajectories as inputs, detect where conflicts may occur, and provide 
as an output suggested avoidance maneuver options to the controller 
[Medioni, 1994; Eby, 1994], A brief description of the types of models 
that form the model categories in Figure 4 is now provided. 
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Trajectory Generation Models 

At the top level, models are needed to define the spatial and temporal 
distributions of aircraft trajectories. Trajectory Generation Models must 
cover several areas: 

(1) Airspace models. Models that define differences between the overall 
route structure or route generation methods in different regions are needed 
for the analysis of free flight on a large scale. For example, aircraft routings 
may be determined differently in transoceanic regions than over continental 
regions. Similarly, limitations in navigational facilities may result in a case 
where free flight may be possible in one region but not possible in another. 
Airspace models define the extent to which free flight is possible in different 
regions (Figure 5). 

(2) Aircraft route generation models. Under the current ATC system, 
routes are typically based on established airways and separation 
requirements. The Free Flight concept would use a route structure in which 
each aircraft plans and modifies its route with limited ground intervention as 
described in Section 2 above. Some aircraft routes may be developed to 
optimize fuel flow, while others may be centered on achieving a desired 
arrival time. Generally, a different set of route generation models would be 
developed for each region defined by an airspace model from area 1 above. 

(3) Local or tactical models of aircraft trajectories. It may be desirable to 
concentrate on the traffic in a local region where two or more aircraft must 
modify their routes to avoid collision or severe weather. Thus, local 
movement models will be needed to analyze the traffic flow within a defined 
region. 


Airspace Model 



Conflict Detection Models 

A second set of models is focused on estimating the rate or density 
of conflicts. Based on the routes obtained from a Trajectory Generation 
Model, a Conflict Detection Model is used to determine where and when 
conflicts may occur. Also, a Conflict Detection Model could provide 
measures of the geometry and number of aircraft involved in a particular 
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conflict. Several initial concepts for conflict detection for free flight have 
been suggested [RTCA, 1995; Winer, 1995]. 

An important part of Conflict Detection is the prediction of where the 
aircraft will be in the future. This prediction can be a simple extrapolation 
based on the current position and velocity vector of the aircraft or can 
include information relating to the intended trajectory of the aircraft. For 
example, knowledge that an aircraft will level off at some altitude can be 
used to inhibit a conflict alert that w'ould otherwise be issued based on a 
continued projection at the current descent rate. 

The aircraft’s position in the future generally becomes more 
uncertain as the extrapolation continues. Thus, even though a conflict is 
projected to occur in the future, it may be the case that the probability of a 
conflict is small. The ability to accurately predict the future trajectory is a 
key issue. Any conflict detection method must balance alerting too early 
and having false alarms against alerting too late and not providing enough 
time or space to avoid an incident. By providing additional state 
measurements or by improving sensor accuracy, it is possible to improve 
performance. Models will be required in this area to design and evaluate 
conflict detection concepts to determine whether there will be an excessive 
rate of false alarms or missed detections. An example study of the methods 
that will be needed to develop these models can be found in [Kuchar & 
Hansman, 1995]. 

Because the severity of a conflict is a function of the ability to 
resolve the conflict, Conflict Detection Models will most likely also require 
data from a Conflict Resolution Model to define what situations are 
sufficiently hazardous to be termed conflicts. 


Conflict Resolution Models 

When aircraft trajectories can be estimated accurately well into the 
future, the interactions between aircraft can be strategic, involving 
negotiation and flight plan changes conducted directly between aircraft or 
through a ground control station. If it becomes clear that a collision is 
imminent, tactical interactions will be required, involving immediate small- 
scale maneuvering to avoid an accident. Aircraft involved in such a tactical 
interaction would then return to their strategic routings after resolving the 
incident. 

A set of models is required to analyze the interactions between 
aircraft when a conflict occurs. As shown in Figure 6, this set includes 
Dynamics, Collision, State Estimation, Alerting, Resolution Selection, and 
Response models. These models will be required for both strategic and 
tactical conflict situations. Example models have been developed for the 
evaluation of the Traffic Alert and Collision Avoidance System (TCAS) 
[Burgess, 1993] and for closely-spaced parallel approach [Shank & 
Hollister, 1992], 
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(1) Dynamics. The dynamics of the aircraft involved in a conflict must be 
modeled. Models of aircraft type, cockpit control and display methods, and 
human performance are included here. 

(2) Collision. A Collision Model is required to determine when collisions 
occur and provides a measure of the effectiveness of the conflict resolution 
system. This model includes the criteria that define a collision (e.g., less 
than 500 ft slant range). In some applications it may be of interest to 
analyze the amount of near miss events, in which case the Collision Mode 
can be modified to define the event of interest (e.g., less than 1000 ft slant 
range). 

(3) State Estimation. The states of the aircraft are estimated by each aircraft 
and/or by a ground control station in some manner, including the use of 
sensors and information transmitted between aircraft or between aircraft and 
the ground A Sensor Model describes the ability of a conflict detection or 
resolution system to monitor each aircraft. This model should describe the 
state variables that are available and the uncertainties present in the state 
estimates. 

(4) Alerting The state estimates are available directly to the pilot or 
controller and/or to an automated alerting or advisory system. An Alertmg 
Model describes the mapping from state estimates to the decision that action 
is needed. This decision is based on the available information and may be 
performed by an automatic alerting system or by a pilot or controller. 

(5) Resolution Selection. Within the Alerting Model, a Resolution 
Selection Model is used to determine what course of action should be taken 
to avoid an accident. Example resolutions include negotiation with other 
aircraft or ATC for strategic rerouting, or tactical, immediate avoidance 
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maneuvers. Several stages of action are also possible, including cautions 
(e.g., “traffic”), restrictive warnings (e.g., “don’t turn left”), and executive 
warnings (e.g., “turn left”). 

(6) Response. A Response Model describes the actions that each pilot takes 
in response to the alerts or other state information regarding other aircraft or 
weather. This model includes human performance parameters such as 
response time, and the complexity and aggressiveness of the maneuver that 
is actually performed. Actions taken by aircraft then are passed to the 
Dynamics Model, which returns updated trajectory information as the loop 
repeats. 


Interactions Between Models 

The Conflict Resolution, Conflict Detection, and Trajectory 
Generation Models are linked together. These connections allow for the 
consideration of multiple aircraft involved in replanning or avoidance 
actions. The evaluation of an ATM concept will require the consideration of 
incidents involving several aircraft at once. A resolution system designed to 
protect against a single proximate aircraft may be inadequate to protect 
against two or more threats. Also, the dynamics of the responses to traffic 
may have repercussions on the routings of aircraft in the local area. Aircraft 
that are not immediately affected by an encounter situation may be indirectly 
affected as the proximate traffic maneuvers. In some situations, instabilities 
in local traffic flow may occur as multiple aircraft respond to multiple 
threats. 


Addidonal, human-centered models will be required to produce 
performance metrics such as pilot or controller workload and capacity to 
respond to alerts as desired. These models must consider the interactions 
between the human operator and the display of conflict information and the 
procedures used to resolve the conflicts (one possible candidate is MIDAS 
[Corker & Pisanich, 1995]). 

Robustness 

As discussed earlier, evaluation of robustness measures will be an 
important function for the conflict models described above. Efficient 
methods for evaluating robustness are likely to include both simulations and 
statistical parameter evaluation methods. Inevitably robustness measures 
must account for and quantify uncertainty. Evaluating the relevant statistical 
measures (e.g., the probability distribution for the number of conflicts over 
some period of time) can sometimes be accomplished by repetitive running 
of simulation models over randomized conditions (i.e., Monte Carlo 
methods). Alternatively, there are often situations where the most effective 
approach is a direct propagation of statistical measures such as probability 
densities or moments. Efficient conflict models are essential in both 
instances. 

For the level of complexity inherent in the Free Flight concept, past 
experience has shown that neither the Monte Carlo nor the statistical 
propagation approach alone is likely to be sufficient. Often the most 
effective method is to combine the two approaches. In some instances 
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Monte Carlo simulations at the micro level can efficiently determine _ the 
necessary input quantities for the macro analysis of a desired global statistic 
through propagation. For this type of evaluation the mathematical models 
serve as the simulation medium for the Monte Carlo analysis and they 
provide the relationships and parameter values for statistical propagation. In 
other instances the reverse procedure is most efficient and a statistical 
evaluation at the micro level creates parameters for randomization of a 
simulation model at the macro level. Once again the mathematical models 
play their appropriate roles but now in reverse order. Experience has 
shown that combinations of the two approaches can provide both the 
flexibility and effectiveness necessary to answer relevant questions in 
quantitative fashion. 


4. Modeling Interactions with TFM 

We now turn to models that would help investigate how Free Flight 
can work in the presence of some of the severe capacity limitations that exist 
in major terminal areas and under less than ideal weather conditions. 
Closely related to this is the general problem of how the traffic flow 
management (TFM) system would be operated in a way most compatible 
with Free Flight. 

Because these questions are so critical, it would seem that a two- 
level modeling approach, one with an emphasis on strategic issues and the 
other on tactical ones, might be required. The strategic model would adopt 
a macroscopic viewpoint and concentrate on developing approximate 
representations of overall traffic patterns under various levels of TFM 
decentralization in the presence of Free Flight. This strategic model would 
necessarily be of a regional or national scope, encompassing a number of 
airports and en route centers. By contrast, the tactical model would be 
microscopic in nature, would look into the detailed behavior of individual 
aircraft, once airborne, and would place its emphasis on a detailed 
examination of the transition from airspace in which Free Flight can be 
accommodated to airspace where it cannot, due to capacity limitations. The 
scope of this tactical model could be limited to a single major terminal area 
of sufficient complexity, e.g., Chicago. 

The Strategic Model 

The strategic model would create an environment (“testbed”) in 
which: (1) the behavior and strategies of ATM system users (airlines and 
general aviation) and TFM operator (the FAA’s central, regional and local 
units) could be represented under a variety of alternative TFM approaches', 
and (ii) the consequences of this behavior and strategies could be explored 
approximately by identifying where the major concentrations of traffic 
would take place and the resulting delays and costs to individual users 
and/or classes of users. Table 1, based on ongoing research at Draper 
Laboratory and MIT indicates some of the types of alternative TFM 
approaches that need to be investigated. An implicit assumption in Table 1 
is that, in the “Free Flight era”, TFM will rely primarily on the “required 
time of arrival” (RTA) method outlined in Section 1 and that specification of 
a “controlled time of departure” (ECDT) from the airport of origin will not 
be necessary. (Whether ECDTs will indeed prove unnecessary is, in fact, 
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one of the many open questions that would have to be investigated with the 
models described here.) 

Table 1 suggests the kinds of modeling capabilities that the strategic 
model should have. For example, under one alternative which is not much 
different conceptually from the existing system (see “Centralized” row in 
Table 1), the FAA-operated TFM would be the sole determinant of 
(dynamic) arrival slot assignments, whenever weather conditions would 
dictate the initiation of a gate-holding “program” for a particular destination 
airport. The TFM system would specify the slot assignment of every 
individual flight and would provide to each flight a required time of arrival 
(RTA) at some location in the terminal area of destination or at some 
distance from it. (This RTA would, of course, be consistent with the 
corresponding slot assignment.) 

The airlines and the other users would then be confined to following 
these TFM mandates, with each airline’s only alternative option being to 
cancel one or more of its flights and utilize the emptied slot(s) for other 
flights of its own -flights that would, otherwise, have arrived at the 
congested airport at a later time. Under such an approach to TFM, Free 
Right would be practiced by airlines (and possibly other airspace users) 
only to the extent of developing and implementing flight plans and 
trajectories that would be consistent with the RTAs assigned to each flight, 
i.e., that would deliver the corresponding aircraft at the specified location at 
the specified time. 

The strategic model must then be capable of simulating how airlines 
would behave in such an environment. For instance, for each given flight, 
an airline would have to determine the “optimal” (from its point of view) 
trade-off between how much delay would be taken on the ground (“gate 
holding”) and how much on the air in order to meet the flight’s RTA. The 
model would also require a capability to examine what would happen in the 
entire ATM system (delays, queue lengths, fuel consumption, etc.) after 
each airline had made its decisions about the (4-D) trajectory of each one of 
its flights. 

Even more advanced capabilities would be required of the strategic 
model to investigate more “decentralized” future TFM environments. 
Consider, for example a partially decentralized TFM system (Table 1, 
“Partially Decentralized I”). Here, the role of the TFM system’s operator 
would be more limited: the FAA would only assign sets of slots to each 
airline for each congested airport over specified periods of time and would 
leave it entirely up to each airline to decide how it would utilize its own set 
of slots in each period. (For instance, UA might receive from the FAA 6 of 
17 available landing slots during the 9:00 to 9:15 tune period at ORD of a 
morning when the arrival acceptance rate at ORD is limited to approximately 
70 per hour, instead of the more typical 100; these 6 slots might be allocated 
to UA to reflect UA’s fraction of total arrivals originally scheduled for ORD 
for between 9:00 and 9:15 that morning.) This means that the airline 
behavior that would have to be simulated extends beyond developing flight 
plans for individual flights that complied with specified RTAs, as required 
under the “centralized” TFM alternative. Now, it is also necessary to model 
how each airline would allocate its available set of slots among those of its 
flights which can utilize these slots. Such a process would have to take into 
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consideration airline “bank” scheduling, flight connections, crew 
connections, etc. It may be extremely difficult to develop such models. In 
addition, the strategic model will need a broader range of capabilities in 
exhibiting aggregate system characteristics since slots, under this partially 
decentralized system would specified in terms of sets over extended time 
intervals (e.g., over 15-minute periods) as opposed to distinct RTAs for 
individual flights. 


The Tactical Model 


As noted above, the tactical model would include a considerably 
higher level of detail than the strategic one but would be of significantly 
more limited scope. It would essentially consist of a detailed model of a 
terminal area with one or more busy airports plus the surrounding en route 
and transitional airspace. The tactical model would emphasize those aspects 
of ATM which are particularly relevant to the dynamic flow management 
functions. Dynamic forecasts of winds and of airport acceptance rates, as 
well as descriptions of the characteristics of the arrival streams and of the 
topology of the terminal area should be features of the model. Most 
important, the model must also include an implementation of the dynamic 
flow management algorithms utilized by TFM. For instance, it should be 
able to capture the effects of a CTAS-like terminal-area automation system, 
as well as of any other techniques used to meter traffic past arrival fixes, 
effect high- and low-altitude holding, exercise vectoring and speed control, 
etc. 

Stochastic Aspects 

Central to both the strategic and the tactical models outlined above 
would be a capability to simulate stochastic phenomena. This is because it 
will be necessary to ascertain the robustness of alternative TFM 
arrangements under Free Flight in the presence of uncertainty due to: the 
variability of airport weather; the consequent probabilistic variations in 
airport acceptance rates; uncertainties about the true airport demand on any 
given day; deviations of actual arrival times at specific waypoints from the 
specified RTAs at these waypoints; etc. 

5. Evaluating Costs and Benefits 

In evaluating any new ATM system concept, it is desirable to 
balance the costs of its implementation and operation against the benefits it 
achieves. There is also the aspect of the timing of costs and benefits since 
costs are likely to be paid initially, while benefits are typically received over 
the long term. This calls for the use of appropriate discounting practices 
that render “commensurable” dollars expended or received at different 
times. Additionally, the development of credible time estimates of benefits 
and costs requires forecasts of future ATM system activity levels. 

There are three categories of participants in ATM who can receive 
significant benefits from innovative ATM concepts: 

a) Aircraft Operators (Airlines, General Aviation, Military) 
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b) Airline Passengers/Shippers 

c) ATM Service Provider 

Each may receive different types of benefits and it is necessary to be 
careful not to double or triple count the same benefit. For example savings 
in operating the ATM system can be passed on to aircraft operators in the 
form of reduced ATM user fees, which can then be passed on to passengers 
in the form of reduced fares. A correct accounting would book this benefit 
only once, but the evaluation should also indicate that three constituencies 
are affected. 
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Table 1: Alternatives for Traffic Flow Management (TFM) 

with Free Flight 



Initial allocation 
of arrival slots 
(1) 

Final assignment of 
arrival slots to 
individual flights 

(2) 

Planning and 
revisions of 
flight trajectories 
(3) 

Centralized 

TFM system operator 
(FAA) allocates 
arrival slots to 
individual flights 

TFM system operator 
(FAA) assigns slots 
(see Column 1); each 
airline may cancel and 
substitute flights 

Airlines (and other 
airspace users); 
TFM system 
operator monitors 
for feasibility, 
conflicts. 

Partially 

Centralized 

TFM system operator 
(FAA) allocates 
arrival slots to 
individual flights 

Each airline suggests 
alternative assignment 
of the slots allocated to 
its (for its own flights 
only; TFM system 
operator approves or 
rejects. 

Airlines (and other 
airspace users); 
TFM system 
operator monitors 
for feasibility, 
conflicts. 

Partially 
Decentralized I 

TFM system operator 
(FAA) allocates sets 
of arrival slots to 
individual airlines 
over time intervals of 
some duration (e.g., 
15 minutes) 

Individual airlines 
allocate their own sets 
of slots among their 
own flights. 

Airlines (and other 
airspace users); 
TFM system 
operator monitors 
for feasibility, 
conflicts. 


Partially 
Decentralized II 

TFM system operator 
(FAA) allocates sets 
of arrival slots to 
individual airlines 
over time intervals of 
some duration (e.g., 
15 minutes) 

Airlines may trade slots 
among themselves. 
Then each individual 
airline allocates its own 
set of slots among its 
own flights. 

Airlines (and other 
airspace users); 
TFM system 
operator monitors 
for feasibility, 
conflicts. 

Decentralized 

TFM system operator 
(FAA) simply 
informs airlines about 
anticipated 
availability of 
capacities at 
potentially congested 
airports. 

Airlines decide what 
they will do. They ! 

may trade slots, cancel 
or delay flights, follow 
the original schedule, 
etc. 

Airlines (and other 
airspace users); 
TFM system 
operator monitors 
for feasibility, 
conflicts. 


Table 1 (continued): Alternatives for 

Traffic Flow Management (TFM) with Free Flight 
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The current Free Flight system envisages a major change in the way 
we do Traffic Flow Management for flights into the major hub airports. 
There would be considerable benefit iri increasing landing capacities, but 
absent such an increase, any benefit in this area must presume that the 
current set of seven methods for executing TFM in the USA is inefficient; 
and that the new TFM method under Free Flight will eliminate these 
inefficiencies. This requires a definition of exactly how the old and the new 
TFM methods work, models to evaluate performance and studies to 
document the current TFM problems at major hubs. 

Similarly, the current Free Flight system envisages an adaptive 
sectorization whereby sector sizes and manning can be quickly redefined to 
allow a re-routing of enroute flows around weather, etc. without 
overloading current sectors. There is a current re-routing tool which has not 
achieved operational status which has the potential to equitably re-route 
traffic subject to current sector workload limits. This new tool should be 
studied to see if the inherent problems in training controllers to work in an 
adaptive sectorization mode are worthwhile. 

The Free Flight ATM concept will evolve, with both new and 
modified versions appearing in the future. Each new concept is likely to 
require operational models to evaluate its performance in one or more 
dimensions. There is a battery of operational models which will be needed 
as well as forecasts of traffic activities and operational costs - for airlines, 
for GA, and for military users; and for specific airspace domains, US 
enroute, Oceanic, Major hub airports, etc. 

There are many aspects of both costs and benefits which must be 
systematically accounted for. A new or modified ATM system is likely to 
involve investments in both ground based and airborne equipment. 
Typically, ground based equipment costs will be borne by the ATM system 
providers while airborne costs must be absorbed by aircraft operators. In 
corresponding fashion other costs such as personnel training, system 
maintenance, software costs etc. will accrue to ATM providers or aircraft 
operators. 

The benefit most likely to accrue from a new ATM system is time 
savings which will result from increased capacity of the ATM system. For 
air trips between certain terminals, in today's ATM system, there are built in 
time delays due to capacity constraints at peak traffic times. In this context 
time delay is defined as the excess time to accomplish a trip, over the trip 
time for a traffic-free flight, as defined earlier. Increasing the capacity of the 
ATM system should allow a direct decrease in the aggregate delays currently 
imbedded in nominal schedules as a result of capacity constraints at peak 
traffic times. For aircraft operators time savings translate into reduced fuel 
and marginal aircraft operating costs, reduced interrupted trip expenses, and 
reduced costs for irregular operations. For passengers the time savings 
should be translatable into equivalent cost savings. For business travel it is 
likely that this time to cost benefit translation can be accomplished rather 
directly though personnel costing. For personal and pleasure travelers the 
translation is more subjective and may require some form of rationalization 
to relate time delays to equivalent costs. 
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In order to correctly evaluate costs for any new ATM system 
concept, models of cost and benefit will be required. In the following 
sections some of the required cost/benefit aspects of these modes will be 
discussed. 

ATM Provider Tost Models -The costs which must be borne by the ATM 
provider are likely to constitute a major portion of the total expense incurred 
using any new ATM concept. Non-recurring costs will accrue for capital 
equipment expenses for the initial development and construction of facilities 
as well as the initial training expenses necessary to implement the concept. 
Recurring costs will accrue for operations and maintenance personnel, 
replacement equipment, and continual training of personnel to maintaui 
proficiency. For any particular ATM concept models of these costs will be 
necessary to allow the evaluation of costs incurred in relation to the benefits 
that may accrue as a result of implementing the concept. These models 
should allow the incorporation of projected growth of traffic and the 
associated required upgrading of the system as a function of ome. As 
discussed above, the cost aspects of traffic flow management and adaptive 
sectorization must be included if Free Flight is to be effectively evaluated. 
An area of particular importance will be costs and potential savings that may 
accrue due to automation. Models must be capable of quantifying the 
tradeoffs between automation and manual operation of various elements of 
any ATM concept. 

Aircraft Oneratnr Tost Models -The operators of aircraft (Airlines, Military, 
GA) are likely to be the major beneficiaries of any new ATM concept and 
cost models of these constituencies will be necessary to quantify projections 
of these benefits. Models for airline personnel costs and marginal aircrait 
operating costs are the most readily available of these three categories. 
These cost models must facilitate the evaluation of airline operator cost 
savings resulting from reductions in delays attributable to ATM capacity 
increases. Models for military and GA costs/benefits will be more difficult 
to realize and are likely to be more subjective in nature. Additionally, ah 
models must quantify the capital expense of new airborne and ground based 
equipment required to allow aircraft operation in any new ATM system, as 
well as recurring costs for maintenance and personnel training. 

Airline Passenger/Shipper C ost Models-As discussed earlier it should be 
possible to create cost models for business travelers directly from personnel 
costs attributable to delays. Similarly, cost models for shippers should 
reflect the marginal costs for shipping that accrue as a result of delivery 
guarantee costs and/or personnel expenses which result from delayed 
shipments. In addition some means of quantifying equivalent costs for 
personal and pleasure travel must also be determined. These costs are far 
more subjective in nature and not as readily and objectively defined as for 
business travelers and shippers. Models which facilitate parametric studies 
over ranges of possible values may be the most useful approach for these 
classes of travelers. 

rVimmon Requirements for Cost Models -All of the cost models should be 
capable of and/or be adaptable to both deterministic and probabilistic 
studies In many instances there will be a need for a direct evaluation or 
costs based on a specific set of parameters. For example, an aircrait 
operator model should be capable of determining the change in marginal 
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costs for a given airline which results from an ATM capacity increase for a 
specific trip between two cities. In addition, the aircraft operator model 
must also be a capable of adaptation to and/or integration with other models 
to obtain statistical estimates of relevant cost statistics. An example here 
might be the determination of the expectation and possibly higher order 
statistics (e.g. standard deviation etc.) for total dollar savings for airlines 
and total costs for an ATM free-flight concept. In particular, the model 
would incorporate uncertainties due to weather, economic forecasts over 
both time and geographical regions, and possibly projections of technical 
capabilities and costs affecting levels of automation for the ATM system 
concept. 

ATM Capacity Integration Model -To be most useful the cost models 
described above must be amenable to integration with other models so that 
the costs and benefits of increased ATM system capacity can be evaluated. 
In particular, the conflict models described earlier are essential for 
quantifying capacity increases that may be achievable with any particular 
ATM concept. The cost models described in this section create the 
relationships between capacity increases and cost benefits to various 
constituencies. Similarly, both the recurring and non recurring costs to both 
the ATM operators and the users, would also be obtained from these 
models. Implicit here is the need for a simulation of an ATM concept over a 
desired time period, appropriately discounting costs and benefits over time. 
An ATM Capacity Integration Model would provide the framework for this 
time line simulation by facilitating the integration of the various models 
described earlier. This model would serve as an integration medium. It 
would establish the necessary initialization and information transfer facilities 
between models necessary for the wide range of tradeoff studies which are 
likely to be necessary to evolve a truly effective ATM concept. To be 
effective this portion of the overall modeling capability must function much 
like a modem computer operating system, creating appropriate user 
interfaces, managing resources, facilitating interchange of information and 
creating an appropriate environment for effective utilization of the various 
models and associated data bases. 
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Appendix B: Case Study on 

Airport Surface Traffic Management Automation 

1. Purpose 

This is a report on the second case study carried out under the MTT Model Review 
and Evaluation project undertaken in connection with NASA's AATT Program. The 
purpose of this document is to identify in generic terms the modeling capabilities needed by 
researchers to study issues in Airport Surface Traffic Management (ASTM). It focuses on 
the evaluation of new technologies for Communications, Navigation, Surveillance, and 
Human-Centered Automation which have the potential to improve safety, reduce delays, 
and lessen controller workload at busy commercial airports in the US. It is desirable to 
evaluate these new concepts to assess their operational feasibility and their costs and 
benefits before embarking on a major R&D effort or implementation program. Models are 
needed to perform these evaluations. 

Four main factors motivate ASTM. The first is the occurrence in the past few 
decades of several aircraft collisions on airport surfaces and many more near misses; it is 
hoped that the enhancements made in managing surface traffic will both reduce the number 
of such incidents and help in resolving those that do occur more rapidly. The second is the 
existence of delays in travel between the runways and the gates; better scheduling and 
communications may streamline this procedure. Third, the task of managing the traffic on 
the airport surface is currently performed solely by the controller, allowing some of this 
work to be performed by automated systems could improve efficiency and allow the 
controller more time to deal with critical events. Finally, continual growth in the volume of 
air traffic is exacerbating all of the aforementioned problems. 

In order to illustrate the modeling capabilities needed to evaluate the impact of the 
planned changes to surface traffic management, this paper is broken down into three 
sections. The first gives general background on airport surface operations. The second 
details the changes to this system being considered and describes how the FAA's ASTA 
program would implement them. Finally, the modeling capabilities needed to evaluate 
surface traffic automation systems are outlined. 

2. Description of Operations on the Airport Surface 
2.1 - Airport Generic Layout 

A schematic for a generic airport surface layout of the taxiways, roadways, and 
parking gates is shown in Figure 1. At a typical busy airport there are one or more 
runways dedicated to either landing operations, or takeoffs, or perhaps both operations. 
The assignment of landing or takeoff operations to the runways by type of aircraft will be 
called a Runway Operating Configuration. Every runway has a full-length parallel 
Runway Taxiway which is used for one-way traffic depending on the direction of use of 
the runway. 

Then there are the Access Taxiways which are used to connect the Runway 
Taxiways to the ramp areas. Access taxiway segments can be used in one direction at a 
time depending on the Runway Operating Configuration in use. At any point in time, there 
is a limited set of one-way taxiway segments in use depending on the runway configuration 
- one set for taxi-in traffic flows, branching out from the landing runways in a tree-like 
structure to reach the various ramp areas; - another set for taxi-out traffic flows converging 
on the takeoff runways from the ramp areas in a root-like structure with a number of merge 
points. There are usually a number of crossing points between the tree and root structures 
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of the taxiways and the runways. The goal of the airport layout designer is to minimize the 
number of these crossings if possible. 

FIGURE 1 - GEOMETRIC ELEMENTS OF THE AIRPORT SURFACE 



The Access Taxiways connect into the Gate Taxiways which may consist of a 
pair of parallel, circumferential, one-way taxiways surrounding the gates. This pair of 
taxiways allows traffic flows both ways between the gates for all runway configurations; 
and unlike the rest of the taxiways, they normally maintain the same directionality 
independent of the runway configuration in use. 

The schematic shown in Figure 1 is very much simplified. Every airport has its 
unique layout, and a unique set of surface traffic flows and problems which arise from that 
layout as it has developed over time. Research into operational concepts for ASTM 
requires that analytical and simulation models should be very adaptable to quite different 
airport layout configurations and allow for easy modification of the geometry and traffic 
procedures. 


2.2 - Airport Surface Vehicles 

There are two types of vehicles on the airport surface; 

1) the aircraft which use the taxiway system to taxi-in and taxi-out between the 
runw'ays and the ramp areas around the gates/parking positions, cargo areas, etc.; 
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2) the various airport and airline ground service vehicles which may use their own 
airfield roadways, or may be using the taxiways and runways (inspection, snow 
removal), and which are active in the ramp areas around and between the gates. 

These vehicles move at a wide range of speeds depending on location, traffic, 
visibility, day/night, etc., as there are no speed limits or expected speeds on the aiiport 
surface. Aircraft cannot see behind themselves generally, and many pilots cannot see either 
their wingtips or their engines and may need assistance in close maneuvering in the ramp 
area to avoid other aircraft, buildings, or snow banks, and to avoid causing damage by jet 
blast. 


2.3 - Current Airport Surface Traffic Management 

Today's concept for traffic control on the airport surface may be termed the Free 
Taxi" concept. The landing and takeoff operations are controlled by the Local Control 
sectors in the Tower. After landing and clearing the runway at some exit selected at the 
pilot's discretion, Local Control will handoff the aircraft to Ground Control. The aircraft 
may then be asked its destination on the airport, and will be given a "Taxi Clearance from 
its current location via a routing specified in terms of taxiways and intersections which have 
various names. Pilots are expected to provide their own Navigation, Guidance and 
Separation Assurance, although Ground Control may intervene from time to time to resolve 
meetings at a crossing or merge point, or to provide a clearance to cross a "live" runway. 
All vehicles which are allowed out onto the airfield and its taxiways usually must have 
voice radio contact with Ground Control to provide the Communication function. Aircraft 
rea dy to leave the gate will call Ground Control for Taxi Clearance identifying their 
location on the airport, and normally are assigned to a takeoff runway and receive a routing 
at that time. 

The Navigation and Guidance functions are manual and visual. Pilots and drivers 
need reasonable visibility to proceed, and are assisted by taxiway edge lighting, perhaps 
taxiway centerline lighting, and more recently, a standard set of large, lighted signs to 
identify the intersections, runways, and taxiway segments. 

The Surveillance function (needed in the Tower(s) and each aircraft and vehicle) is 
also manual and visual, although there are some very primitive systems of surface 
surveillance using radar. There are many instances today where the visibility from the 
Tower is not sufficient for the Ground Controller to see the traffic on certain parts of the 
airport, and at night it is difficult to maintain identity of a set of navigation lights (or yellow 
caution lights on ground vehicles) as they move around the taxiway network. 

In the principal ramp areas, there may be several independent Ramp Traffic Control 
sectors for aircraft and various ground vehicles. Such Ramp Traffic Control may be 
provided by each airline at a US airport to establish the sequence of gate arrival and 
departure operations (gate assignment, gate arrival guidance, unloading, refueling catering, 
cleaning, loading, pushback, snow and ice removal, etc.). Most of the ground handling 
vehicles on the ramp do not have radios and are individually responsible for their routings 
and separation assurance (there usually is some traffic training required to qualify to dnve 
ramp vehicles). These Ramp Traffic Control sectors receive advisories on gate holds 
desired for ATC Congestion Management directly from the Ground Traffic Control sector, 
and conversely, advise Ground Control whenever the gates are full and cannot accept any 
more arriving aircraft. 


159 



2.4 - A Generic Description of Airport Surface Traffic Management 
Processes 

The interrelationships between various ATC and ASTM processes is shown in 
Figure 2. As traffic flow rates approach capacity rates, these processes cannot remain 
independent and are forced to work together to achieve Congestion Management. In the 
following discussion the items of information which they must supply to each other in such 
circumstances are identified as their activities are described. There are two different aircraft 
traffic flows as mentioned above: the flow of arriving aircraft which starts before landing 
and results in the Taxi-In flow on the inbound taxiway route structure; and the flow of 
departing aircraft which starts before gate departure and results in the Taxi-Out flow on the 
outbound taxiway route structure. 

2.4.1 - The Arrival Flow of Aircraft 

The existing ATC processes of Enroute ATC, Terminal Area ATC, and ATFM 
control the arrival flows of aircraft at the airport in response to forecasts of its landing 
capacity. From the ATFM process an initial rough estimate of Estimated Time of Arrival at 
the planned Entry Fix (ETAF) can be provided and updated from time to time whenever a 
significant change is noted. From the Terminal Area ATC process, an assignment to a 
landing runway and an Estimated Landing Time (ELT) can be provided with roughly 30 
minutes warning. Both of these items are subject to change until a few minutes before 
landing, since there could be an unexpected change of Runway Configuration. ETAF and 
ELT are the parameters needed by ASTM from the ATC processes. There is a high degree 
of uncertainty in their values at any point before actual landing. Missed approaches or 
aborted landings further increase uncertainty. 
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FIGURE 2 - INTERRELATIONSHIPS OF ATC & ATSM PROCESSES 



AIRLINE RAMP HANDLING 


The runway exit which the pilot will elect to use and the time of arrival at that exit can be 
estimated (ETX) as a function of runway surface conditions, aircraft type, wind, visibility, 
etc., but is also subject to considerable uncertainty. While the Ground Control Sectors of 
ASTM can do some preliminary surface traffic planning, the decisions on the inbound 
traffic routing can only start when the aircraft actually enters the runway exit at the actual 
time of exit (ATX). This event will be obtained from airport surveillance after it happens. 

To plan a routing. Ground Control also needs the gate assignment (or ramp area) to 
which the aircraft has been assigned by the Ramp Control process. By providing an estimate 
of landing times (ELT) to Ramp Control, and perhaps an initial Forecasted Time of Arrival at 
the Gate or Ramp Area (FTAG), Ground Control expects to receive back an assigned gate 
and its Estimated Time of Gate Ready (ETRG). This exchange can occur before landing, so 
that at ATX the ASTM process can quickly determine the taxiway routing and provide a new 
Estimated Time of Arrival at the Gate (ETAG) for Ramp Control. If ETRG exceeds ETAG 
by some amount, Ground Control may have to plan a different route to some area of the 
airport where aircraft can be held clear of the Ramp Area during their Taxi- in. Again there is 
some uncertainty in the estimate for ETRG, since it depends on the expected performance of 
various gate departure activities by Ramp Control. Ramp Control may change the Gate 
Assignment depending on whose actual progress. 
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2.4.2 - The Departing Flow of Aircraft 

A variety of Ramp activities prepare an aircraft for pushback from the gate (flight 
planning, weight and balance planning, cabin cleaning, loading of cargo and passengers, 
loading of catering supplies, snow removal, refuelling, readiness of pushback crews and 
equipment, repair of minor faults in aircraft equipment, etc.). It is difficult to provide with 
a high degree of confidence, the estimated time of being ready for pushback (ETRP) which 
is required by ASTM. At some point, the actual time of being ready to pushback (ATRP) 
can be announced by Ramp Control. It may be accompanied by a request for a latest time 
of pushback clearance (LTCP) so that a gate can be cleared for an arriving aircraft. 

Given these items of information, ASTM can plan an estimated time of pushback 
clearance (ETCP), an aircraft routing to an assigned takeoff runway (which could involve 
an assignment to a holding area somewhere on the airport surface), an estimated time of 
arrival at the takeoff runway (ETRA), and an estimated time of takeoff (ETTO). To do this 
planning, estimates are required from Terminal Area ATC and Tower Control on the 
capacity of arrival and departure flight operations and their current and planned backlogs; 
and from the ATFM process, information is needed on possible Ground Holds caused by 
traffic congestion at the destination airport of each individual flight. There is a high degree 
of uncertainty in all these estimates, and significant updates will occur with actual progress 
of runway operations and with changes in runway configuration, weather, etc. 

Under certain situations where there is a lack of capacity in the Departure sectors of 
ATC, it becomes desirable for Ground Control to provide a certain sequence for takeoff 
aircraft. Rather than have a series of aircraft all departing southbound, for instance, 
departure capacity is increased by providing an alternating sequence of southbound and 
northbound aircraft. An aircraft destined for some takeoff runway may be instructed to 
wait at some taxiway intersection until another aircraft can pass it and precede it in the 
takeoff sequence. While this can be pre-planned as part of the runway assignment process, 
it will become part of the tactical control of aircraft movements on the airport surface, as 
described below. 


2.4.3 - Separation Assurance for Surface Traffic 

The surface traffic routings for all aircraft and ground vehicles can be supplemented 
with estimated times of arrival at intersections which would then allow an indication of 
possible conflicts between them. As mentioned above there is a wide variation in taxi 
speeds amongst pilots and no limitations imposed on planned taxi speeds at present. Under 
such situations, there is a high degree of uncertainty in predicting taxiway conflicts over a 
longer time horizon. This results in today’s application of "Free Taxi" where a very short- 
term tactical concept is used for Separation Assurance. It is possible to conceive of an 
automated Surface Collision Avoidance System (SCAS) which would use good 
surface surveillance to provide a very short-term alert (15 seconds) to pilots and Ground 
Controllers about impending encounters. It would be useful in very bad visibility 
conditions which occur rather infrequently at most airports. 

There are taxiway layouts which can result in "gridlock" if Ground Control does 
not carefully organize the sequence of aircraft movements. Usually these occur at the entry 
points to the Ramp from the circumferential gate taxiways where inbound and outbound 
flows cause multiple aircraft to meet each other at complex taxiway intersections. 
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3.0 - New Technological Capabilities for ASTM 

There are a number of new technologies which have the potential to streamline 
surface trafffic operations and improve safety at major airports. The FAA’s ASTA 
program (References 2, 3, 4) incorporates most of these in four stages of implementation, 
as shown in Table 1. 


3.1 - Surface Surveillance 

Until recendy, surface surveillance in most major airports relied exclusively on 
visual contact. Twelve had a primitive Airport Surface Detection Equipment (ASDE) radar, 
ASDE-2, airports which was hampered by display clutter and difficulty of maintenance. 
This situation is being improved by the introduction of ASDE-3 at about 40 major airports; 
the system is expected to provide consistent high-quality radar surveillance of the airport 
surface. The data produced by the system is also suitable for computer analysis, facilitating 
automatic conflict-detection software and eventually traffic management aids. While this 
solves the problem of locating aircraft on the surface, it does nothing to identify them; all 
aircraft look identical on the display. In order to address this shortcoming another system 
is required; the most popular option to date has been a Mode-S Beacon system. 

Complex Mode-S beacon systems are already in use for en-route and terminal 
surveillance; a surface implementation would be simpler, consisting only of five to seven 
antennas and associated electronics placed around the edge of the airport. The system 
receives the signals emitted by an aircraft's Mode-S transponder, which include the identity 
of the aircraft, and use differences in reception time at the various antennas to fix its 
location. This allows for a tower display showing the location and identity of all surface 
aircraft equipped with Mode-S transponders. Aircraft not so equipped would register on 
ASDE-3 and appear on the display without identification. 

Another system which is now being considered is the Differential Global 
Positioning System (DGPS), which uses satellites to determine an aircraft's position in a 
manner similar to the use of the antennas in the Mode-S beacon system. This system has 
high precision and is already being used for ground and sea transportation, but it would 
require retrofitting aircraft with DGPS transmitters and receivers. 

Table 1. Stages in the FAA's ASTA Program 

AMASS Audible Alerts in Tower 

ASDE Display Enhancements 

ASTA-1 Runway Status Lights 

Runway Status on ASDE Display 

ASTA-2 Data Tags on ASDE Display 

Departure Sequencing Aid 
Taxi-Route Compliance Monitoring 
Airport Configuration Management Aid 

ASTA-3 Surface Traffic Data in Cockpit 

Audible Alerts in Cockpit 
Active Taxi-Route Guidance 
Traffic Planning Aid 
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Digital Data-link 


3.2 - Automatic Alerts 

AMASS includes software which constantly evaluates the surface traffic situation as 
described by the ASDE-3 radar and creates an audible alarm in the tower when a hazardous 
situation develops. It is hoped that this will attract the controller's attention to the situation 
early enough to avert a collision. Once digital data links are implemented as described 
below, it will also be possible to have automatic conflict alerts sound directly in the cockpit, 
saving the time it would otherwise take for the controller to assess the situation and 
communicate it to the pilot. For both kinds of automatic alerts, the ideal system would 
detect all genuine conflicts and yield no false alarms or "nuisance alarms (alerts sounded 
because the alerting criteria are violated while there is no true risk of a collision) although 
any real-world system will at best approximate these properties. 

3.3 - Runway Status Lights 

The automatic conflict alerts in AMASS are useful for detecting potential collisions 
and resolving them but do little to prevent conflicts in the first place. To this end, ASTA-1 
includes a system of two kinds of runway status lights. The first set of lights are runway- 
entrance lights, placed wherever a taxiway intersects a runway. The lights indicate to 
aircraft on the taxiway whether or not it is safe to cross the runway. The second set of 
lights are takeoff-hold lights, indicating to aircraft at the beginning of a runway whether or 
not they are cleared for takeoff. In order to keep controller workload low, these lights are 
operated automatically; a complex algorithm analyzes surveillance data to determine which 
crossings and runways are clear and operates the lights accordingly. The system is not 
designed to replace clearance from the controller, merely to supplement it. Clearly, the 
light management system must be carefully designed so as to agree with the controller on 
when it is safe to cross a runway or take off in order to avoid confusing the pilot with 
contradictory clearances. 


3.4 - Digital Communications 

The introduction of digital datalinks to provide data transfer between ground 
computers and aircraft computers is a source of many potential ASTA enhancements. 
These datalinks could use VHF and UHF radio, Mode-S, or satellite links. Some 
functions which are currently done by voice channel, such as taxi route clearance and 
compliance monitoring, could be accomplished more efficiently through digital data 
transfers. This would clear the chatter on the voice channels, streamlining operations and 
making it easier for the controller to get the pilot's attention. Other information which 
could be transferred via the data link includes weather data, direct cockpit conflict alerts, 
and delivery of surface traffic data to the cockpit. Providing the pilot with such information 
offers yet another chance to prevent conflicts after the controller and the automatic light 
system have evaluated the situation, as well as helping the pilot to understand overall events 
on the airport surface. 

3.5 - Automated Planning Aids 

With the advent of surveillance tools such as ASDE-3 and the Mode-S beacon 
system, it is possible to create computer programs to help manage surface traffic flow. 
ASTA-2 includes a departure-sequencing system which would make use of flight plan data 
and surface traffic conditions. ASTA-3 will include some form of traffic planning aid 
which will generate a tentative surface traffic plan for controller approval and coordinate 
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this plan with other ATC automation systems. Also possible are such tools as a runway 
configuration aid, designed to choose the ideal runway configuration given surface and air 
traffic data as well as organize transitions from one configuration to another. 


3.6 - Computer Displays 

In order to make use of better information, new displays are needed. AMASS, in 
the case of a conflict, adds to the ASDE display information and is useful in resolving a 
hazardous situation rapidly. It also adds an approach bar to the display for each active 
runway, indicating the location of incoming aircraft. ASTA-1 incorporates the runway 
status information used to operate Runway Status lights. ASTA-2 is scheduled to include 
data tags on the ASDE display (probably obtained from a Mode-S system, although that 
has not been finalized). Design of cockpit computer displays will also become an issue as 
digital data-links allow for automated clearances and surface traffic data in the cockpit. 
Careful design of the cockpit display is needed since the pilot is being asked to share his 
attention between a heads-down computer display and looking out the window. The pilot 
should be able to quickly obtain pertinent information without being distracted by irrelevant 
data. 


4.0 - Modeling Requirements 

Before initiating any plan to implement airport surface traffic automation on a large 
scale, it is important to verify that such automation is warranted. The FAA initiated the 
ASTA program with the aims of reducing the number of hazardous events and collisions on 
the airport's surface, the amount of delay suffered by aircraft on the airport's surface, and 
the workload of pilots and airport surface controllers. The nature of the problems in these 
areas should be evaluated carefully to make sure the changes being considered would result 
in a significant improvement over existing conditions. This calls for extensive modeling 
capabilities. A variety of models, both analytic and simulation, are needed for this 
purpose. Additional modeling requirements are imposed by the need to evaluate carefully 
the costs and benefits of A STM systems. In this section we review some of the primary 
types of models that are needed, along with the capabilities they should possess. 

One feature common to all of the models is applicability to a variety of airports. 
Because many airport surface problems are of a local nature and depend heavily on airfield 
configuration, it is highly probable that some of the ASTM tools to be developed will have 
to be location-specific, while some other tools may have to undergo extensive modification 
for adaptation to local conditions. The need for (and potential benefits from) advanced 
ASTM tools will also vary from airport to airport and it is conceivable that the benefits may 
not justify the costs at some or many airports. 

4.1 - Conflict Avoidance and Accident Causality 

Some of the ASTM tools under consideration are primarily intended to either 
prevent conflicts on the airport's surface or to identify and resolve them well in advance. 
Most of these approaches are dependent on software and hardware which automatically 
recognizes a developing conflict and then initiates a process that would prevent an actual 
collision. It is important to note that identifying correctly a potential conflict on the 
airport's surface is far from an easy task. There are no speed requirements on taxiways, so 
aircraft move at the speed that the pilot feels is appropriate; this makes it difficult to predict 
the time at which an aircraft will reach a specific location. It is also probable that one of 
two aircraft predicted to encounter each other will change course or speed before the 
predicted encounter can occur, especially since, for the system to be of any use, the conflict 
must be identified early enough to allow for reaction time and in some cases 
communication. Clearly the potential for many false alarms exists in such an 
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environment. The capabilities required to evaluate such problems and issues should 
therefore include the modeling of various levels of uncertainty about (current and future) 
positions of aircraft, future intentions of aircraft, response and reaction times, etc. A high 
level of model flexibility is also necessary, so that many alternative scenarios along these 
lines can be explored. 

In order to evaluate the safety benefits of a surface traffic automation measure, a 
good understanding and, if possible, a model of the causes of surface accidents is also 
needed; the data from a simulation incorporating the ASTM change made and the data from 
normal operations can then be used to compare the relative safety of the two modes of 
operation. The model should identify the factors leading to the occurrence of a conflict as 
well as the factors contributing to the chance of successful conflict resolution. It is 
important to define for these purposes exactly what comprises a "conflict". In studies to 
date, the cases considered have included both actual collisions and instances where 
controller intervention was deemed necessary to prevent one. This provides a set of data 
for analyzing the causes of a conflict; but the inclusion of cases of intervention may 
overstate the frequency of true safety hazards, as it is conceivable that some or many of 
these interventions may have been unnecessary ones or may even have themselves 
triggered a more serious conflict than would otherwise exist. Care must be taken that the 
model does not confuse perceived need for intervention with the true causes of potential 
accidents. 

4.2 - Cost Models 

While many of the automation measures mentioned in Section 3 are likely to have 
some positive effects, they also require money and effort to implement. In order to make 
informed decisions about the value of installing these systems, methods for valuing their 
costs and benefits are needed. In order to understand how various distinct groups benefit, 
separate models should be devised for airlines, passengers, and airports. Factors such as 
passenger delay time, aircraft delay time at the gate and during taxiing, and fuel used 
during delays should be assigned monetary values to determine the value of performance 
improvements. Most difficult, such factors as safety and controller workload should be 
brought into the picture somehow, preferably through the assignment of monetary values to 
them. The cost model for implementing changes should factor in research and development 
cost, testing, installation, revision of operating procedures, retraining for the new operating 
procedures, and maintenance of the new systems. 

4.3 - Human Factors 

Simulators are needed to study the interaction between the human operators and the 
automation systems. One simulator should represent the situation as seen from the tower 
and provide realistic surface traffic scenarios with an interface appropriate for the 
automation systems in use. Another simulator is needed for the pilot's perspective, 
providing an "external" view of the airport, communications, and data appropriate for the 
automation systems being simulated. These simulators should be adaptable to different 
operating procedures, display formats, airports, and operating conditions (such as rain, 
snow, low visibility, and configuration changes.) They should include factors which 
would complicate traffic scenarios in real airport operations, for instance human error and 
under-equipped aircraft (such as those lacking a Mode-S transponder or sophisticated 
display equipment, depending on the automation systems being simulated.) They should 
also be able to operate in real time even for high traffic situations and use both custom and 
randomly generated traffic scenarios. The simulator should also be able to record the data 
needed for safety, cost-benefit, and delays analysis, such as: response times; volume of 
communications; aircraft delays at the gate and during taxi; controller/pilot idle time; 
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frequency of pre-defined incidents; frequency of false alarms and nuisance alarms; 
frequency of misinterpreted communications and signals; etc. 

In addition to studying human factors in ASTM, these simulators will be useful in 
obtaining a better understanding of some of the "side effects" of advanced ASTM. 
Reducing pilot and controller workload is desirable as much for its own sake as for its 
impact on other ASTM concerns. For example, a decrease in controller workload might 
lead to a reduction in controller errors, thus improving safety, or in more efficient 
operations as a result of more time to consider delay-reducing strategies for airport surface 
operations. 

4.4 - Fast-time Simulator 

Finally, a fast-time simulator is needed in order to yield data for the analysis of 
capacity, delays and costs. This is essentially a high-speed version of the software used to 
generate situations for the human factors model, with the behavior of both the controller 
and the pilot being simulated instead of just one. However, with the emphasis on metrics 
like capacity and delays, a somewhat lower level of detail and realism than in the case of the 
human factors simulation can be tolerated. On the other hand, in the absence of a simulated 
pilot or controller interface, care must be taken to make the fast-time simulator account for 
communication and response time; plans do not take effect the instant after they are 
conceived in the real world, so they should not do so in the simulation either. It is also 
important that the simulator be able to portray unusual conditions; the performance of an 
automation system will change in the presence of special procedures such as runway 
configuration changes, de-icing, snow removal, and poor visibility. 

Furthermore, since detailed data are desired on the performance of the system as a 
whole, the overall ATM system must be represented more accurately than is necessary for 
the human factors simulators. For example, the simulator should be able to model 
integrated approaches to delay reduction that consider simultaneously gate, apron, taxiway 
and runway delays. One implication of this is that the simulation should not only be able to 
incorporate models of ASTM systems and algorithms for reducing delay, but must also be 
able to capture the interactions of these systems and algorithms with other terminal area 
automation systems, such as future versions of CTAS, that would co-ordinate operations 
on the runway system. Similarly, if they are to function properly in gate and apron areas, 
ASTM systems and algorithms should interact closely with airline information systems and 
that effect should be captured by the simulation model. Clearly, these requirements will not 
be easy to satisfy. 

In addition, as noted earlier, there is a great deal of uncertainty in predicted anival 
times and the timing (or even existence) of anticipated surface encounters, so the associated 
processes in the simulator should include random variation in order to test how the 
automation system handles uncertain quantities. The limits placed on the planning horizon 
of the automation system by this uncertainty are also of interest; the simulator should output 
data on the average and minimum buffers between the formulation of a plan and the 
occurrence of the events it manages. Related to this is the number of times a plan has to be 
modified due to dynamically changing circumstances. A plan formulated well in advance 
will probably go through several revisions, making it more difficult for the controller to 
remember the current plan of action; information on the frequency of plan revisions should 
therefore be output as well. Without these features, the simulator would model a far more 
idealized world than the real one for which automation systems are ultimately intended. 
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List of Acronyms 

ASDE Airport Surface Detection Equipment 

ASTA Airport Surface Traffic Automation 

ASTM Airport Surface Traffic Management 

ATFM Air Traffic Flow Management 

ATRP Actual Time Ready for Pushback 

ATX Actual Time at Runw'ay Exit 

DGPS Differential Global Positioning System 

ELT Estimated Landing Time 

ETAF Estimated Time of Arrival at Entry Fix 

ETAG Estimated Time of Arrival at the Gate 

ETCP Estimated Time of Clearance for Pushback 

ETRA Estimated Time of Arrival at the Takeoff Runway 

ETRG Estimated Time of Gate Ready 

ETRP Estimated Time Ready for Pushback (ETRP) 

ETTO Estimated Time of Takeoff 

ETX Estimated Time at Runway Exit 

FT AG Forecasted Time of Arrival at the Gate 

LTCP Latest Time of Clearance for Pushback 

SCAS Surface Collision Avoidance System 
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Appendix C 


WWW Resources: 


Model homepages: 

U.S.: 

TAAM, Total Airspace & Airport Modeller (Embry-Riddle) 

http://erau.db.erau.edu/~taam/tpg_taam.html 

http 7/ccf. arc. nasa. gov :80./af/aff/midas/M I DAS_home_page.html 
ASAC Charts and Spreadsheets 

http://www.asac.lmi.Org/archive.html/#Charts 


Europe: 

Annette WWW Demonstrator 

http://daedalus.dra.hmg.gb/annette/ 

BADA WWW Demonstrator 

http://daedalus.dra.hmg.gb/annette/bada.html 

Eurocontrol WWW home page 

http://wwwZeurocontrol.fr/ 

http://s4dc8isd.eurocontrol.de/ 

^ * http://www.cenaath.cena.dgac.fr/~klrz/public/Projet_MUFTIS.html 


HIPS Home Page 

http://robin.uneec.eurocontrol.fr/hips/ 


Eurocontrol Experimental Centre 

http://castle.uneec.eurocontrol.fr/ 


DRA - Open Distributed Systems 

http://daedalus.dra.hmg.gb/ 


DERA 


http://www.dra.hmg.gb/ 

NARSIM Home Page . 

http://www.nlr.nl/public/fac/narsim/index.html 
http7/www. nlr.nl/public/fac/narsim/airmod.html 

DLR - German Aerospace Research Establishment 
http://www. dlr.de/ 

AATT Homepages: 


MIT/AATT : 

http://web.mit 


.edu/aeroastro/www/labs/AATT/ 


NAS A/ AATT: 

http://www.nas.nasa.gov/AATT/ 
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